Johnny Martinez, P.E. March5 t 2012 City Manager Recommendation of Evaluation Committee for Informal RFP 291270: Establish, Operate, and Administer Dot Miami hia Torres, Chair Evaluation Committee
As Chairperson of the Evaluation Committee ("Committee") for the above services for the City of Miami, it is my responsibility to offer the findings and recommendation of the Committee.
The City issued Informal RFP 291270 to Establish, Operate, and Administer dot Miami on February 17, 2012 and one (1) Proposal was received on March 2,2012. The Evaluation Committee ("Committee"), appointed by the City Manager, met on March 5, 2012 and was comprised of the following individuals:
1. Vanessa Acosta, Assistant Director Building Dept, City of Miami 2. Camilo Rodriguez, Independent Consultant. BMIT, Inc. 3. Cynthia Torres, Information Technology Department, City of Miami
Following discussion, evaluation and deliberation of the one proposal received, the Committee recommends that the City negotiate with the firm, Minds and Machines, LLC.
Upon successful contract negotiations, the recommendation from the City Manager to the City Commission seeking permission to authorize and execute the professional services agreement will be presented at the next available meeting.
Your signature below represents your approval of the Committee's recommendation.
DATE: _'?,)_·_·1_-_,1-..___ y Manager Informal RFP No. 291270 ESTABLISH, OPERATE, AND ADMINISTER DOT MIAMI
Evaluation Committee Meetin Summary Sheet
Technical and a... Operational 0 +-' C\'I Capacity; ::s Overall Experience and C\'I > TOTAL Ordinal w Qualifications Approach to dot Financial Other PROPOSER and Experience Miami Proposal Questions POINTS Ranking ro ro U) ...... U) U)
N o
.!!! (f) ..c: Q) ...... c ..... Minds and Machines, LLC >,0 2S I/D .;1.0 01 .S erO I ------~------..~:-..- ~------
Informal RFP No. 291270
ESTABLISH, OPERATE, AND ADMINISTER DOT MIAMI
Evaluation Committee Meeting Evaluation Form Evaluator:~~:>\c.- Signature: .~
Technical and Operational Capacity; Overall Experience and Qualifications Approach to dot Other Ordinal Miami
Minds and Machines, LLC ~\ Informal RFP No. 291270
ESTABLISH, OPERATE, AND ADMINISTER DOT MIAMI
Evaluation Committee Meeting Evaluation Form
Technical and Operational Capacity; Overall Experience and Approach to dot Other Miami
Minds and Machines, LLC / Informal RFP No. 291270
ESTABLISH, OPERATE, AND ADMINISTER DOT MIAMI
Evaluation Committee Meeting Evaluation Form
, ------I Evaluator: (.1 I t VI- -i-k-l{ _ 0 «(2..2 Date:
· t ~ / ~7) .(' /\'\ /' S Igna ure ~'A4_kd"'" ~/~/
Technical and Operational Capacity; Overall Experience and Qualifications Approach to dot Financial Other TOTAL Ordinal Miami nds and Machines, LLC f To: Johnny Martinez, P.E. FebruarY 27, 2012 City Manager Selection of an Evaluation Committee for Informal RFP No. 291270 Establish, Operate and Administer From: Cindy Torres dot Miami Director Department of Information Technology
. This memorandum is seeking your approval for appointments to the Evaluation Committee for the selection of a qualified firm(s) to Establish, Operate and Administer dot Miami.
Each of these individuals is knowledgeable and experienced professionals, and will be an asset to this evaluation process. Pursuant to Ordinance 12271, Section 18-86, (C)(6) Proposal Evaluation, "An evaluation committee shall be appointed by the City Manager 'for the purpose of evaluating Proposals based upon the criteria contained in the RFP ... "
Those individuals are:
(1) Vincent Betancourt, Film Industry Liaison, City of Miami (2) Camilo Rodriguez, BMIT, Inc. (3) Cynthia Torres, Information Technology DE;!partment, City of Miami
The alternates are:
(1) Arturo Duque, Information Technology Department, City of Miami (2) Vanessa Acosta, Assistant Director, City of Miami Building Department
Your signature below affinms your appointment of these individuals to become Evaluation/Selection Committee members.
APPROVED: -..:....~l":---:-:-"-:t=::....;;;..;~~-- DATE: _~_-_\_""_l_t.___ Response to . RFP 291270 Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI
by
March 1, 2012
i '
RFP 291270 Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI Certification Statement Please quote on this form, if applicable, net prices for the item(s) listed. Return signed original and retain a copy for your files. Prices should include all costs, including transportation to destination. The City reserves the right to accept or re:Ject all or any part of this submission. Prices should be firm for a minimum of 180 days following the time set for closing of the submissions. . In the event of en'ors in extension of totals, the unit prices shall govern in determining the quoted pnces.
We (I) certif)1 that we have read your solicitation, completed the necessmy documents, and propose to furnish and deliver, F.O.R. DESTINATION, the items or services specified herein.
The undersigned hereby certifies that neither the contractual party nor any of its principal owners or persOlmel have been convicted of any of the violations, or debarred or suspended as set in section 18- J07 or Ordinance No. 12271. . All exceptions to this submission have been documented in the section below (refer to paragraph and section).
EXCEPTIONS: The proposer wishes to assert an exception to the P.o. 's Terms and Conditions, specifically to Section 15, which directly contradicts Section 2.3 of the IRFP, which sets a 5-year contract with a 2-year option; and to Section 25, which contradicts the City's Feb. 27 2012 Addendum, A16, which confirms "no Performance/Payment Bond [is] required for this RFP." We (1) certifY that any and all infonnationcontained in this submission is true; and we (1) further certify that this submission is made without prior understanding, agreement, or connection with any corporation, firm, or person submitting a submission for the same materials, supplies, equipment, or service, and is ill all respects fair and without collusion or fraud. We (I) agree to abide by all tenns and conditions of this solicitation and certify that I am authorized to sign this submission for the submitter. Please print the following and sign your name:
SUPPLIER NAME: Minds and Machines LLC Miami Address: 3301 N.E. 1st Ave, Suite L307, Miami FL 33137 ADDRESS: Main office: 3100. Donald Douglas Loop N., #7, Santa Monica CA 90405
PHONE: 310-452-1491 FAX: 646-365-3000
EMAIL: [email protected]
SIGNED BY: Antony Van Couvering
TITLE: _C_E_O______DATE: February~
fAILURE TO COMPLETE. SIGN. AND RETURN THIS FORM SHALL DISQUALIFY THIS BID.
Page 2 of 34 Certifications
Legal Name of Finn: Minds and Machines LLC
Entity Type: Partnership, Sole Proprietorship, Corporation, etc. Limited Liability Corporation
Year Established: . 2009
Office Location: City of Miami, Miami-Dade County, or Other Main fice: Other; Florida location: City of Miami
Occupational License Number: . Pending
Occupational License Issuing Agency: Miami-Dade County and/or City of Miami
'Occupational License Expiration Date: Date unknown pending approval
Respondent certifies that (s) he has read and understood the provisions of City of Miami Ordinance No. 10032 (Section 18-105 of the City Code) pertaining to the implementation of a "First Source Hiring Agreement.": (Yes or No) . Yes
Do you expect to create new positions in your company in the event your company was awarded a Contract by the City? (Yes or No) Yes
In the eventyour answer to question above is yes, how many new positions would you create to perform this work? 5
Please list the title, rate of pay, summary of duties, number of positions, and expected length or duration of all new positions which might be created as a result 6fthis award of a Contract. Manager, $150K, 5 yrs, executive; 2. Mktg Director, $130K , 5 yrs, marketingi 3. Miami ~isonr S80K, 5 yrs, liaison with City of Miami; 4.Community Liaison, $80K, 5 yrs, liaison wi' :mli community; 5. Mktg Assoc., $50K, 5 yrs, assistance with marketing Will Subcontractor(s) be used? (Yes orNo) Yes
Page 3 of 34 Table of Contents
1 C;om pa ny Information ...... 3 1.1 Contact Information ...... ; ...... 3 1.2 Company Overview ...... 3 1.3 Relevant Expertise ...... 6 1.4 Company Financial Information ...... 10 1.5 Contracting Party ...... 12 2 Technical & operational capacity, experience and approach ...... 14 2.1 Project and Relationship Management ...... 14 2.2 ICANN Application ...... 16 2.3 TLD Capability and Capacity ...... 19 2.4 TLD Expertise ...... 21 2.5 IPv6 ...... 32 2.6 Security and Stability ...... 33 2.7 Data Protection and Law Enforcement Access ...... 33 2.8 Accounting and Reporting ...... 40 2.9 Policy Development ...... :...... 40 2.10 Customer Support ...... 43 2.11 Human Resources ...... ; ...... 44 2.12 Marketing ...... : ...... 45 2.13 Compliance ...... 47 2.14 Transitioning ...... , ...... 48 3 Financial Proposal ...... 49 3.2 Alternative Financial Proposal ...... ~ ...... 51 4 Other Questions ...... 51 4.1 Other Information...... 51 4.2 References ...... 52 4.3 legal ...... 52 4.4 Conflicts of Interest...... : ...... : ...... 52 5 Glossary ...... 54
6 List of Attachments ...... 57 6.1 Attachment 2.8.1 - Sample Reports ...... 58 6.2 Attachment 2.9.1- Policy Framework...... 58 6.3 Attachment 3.1.6 - Expected Case Financials ...... 59 6.4 Attachment 3.1.6 - Optimistic Case Financials ...... 60 6.5 Attachment 3.1.6 - Worse Case Financials ...... 61
RFP 291270 2 . Informal Request for Proposals to Establish, Operate, and Administer dot M lAM I 1 Company Information
1.1 Contact Information
1.1.1 Company/organization name (including legal and trading names if applicable);
Minds and Machines, LLC (referred to throughout this RFP as "M+M")
1.1.2 Headquarters registered address:
3100 Donald Douglas Loop North; Hangar 7, Santa Monica, CA 90405,
1.1.3 Postal address (if different):
As above.
1.1.4 Name and position of contact person for information and inquiries:
Antony Van Couvering, CEO
1.1.5 Telephone:
(310) 452-1491 land line; (917) 406-7126 mobile
1.1.6 Email address: [email protected]
1.2 Company Overview
1.2.1 Company structure
M+M is a limited liability company established under the laws of the State of California.
1.2.2 Ownership structure, including whether publicly traded or not, shareholdings , greater than 10%, or board and governance structure, and objectives if nonprofit
M+M is a private company, wholly owned by Top Level Domain Holdings, Ltd. ("TLDH"), a publicly traded company. TLDH is a publicly traded company on the AIM market of the London Stock Exchange, traded under the ticker symbol TLDH. Shareholders of TLDH with greater than 10% ofthe outstanding shares are Fred Krueger (Board member of TLDH). TLDH is managed by a board of directors consisting of five executive and two non-executive members, as follows: Peter Dengate Thrush, Executive Chair; Antony Van Couvering, CEO; Fred Krueger, Chief Strategy Officer; Guy Elliott, Chief Investment Officer; David Weill, Chief Financial Officer; Clark Landry (non-exec); and Michael Mendelson (non-exec),
RFP 291270 Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI 3 1.2.3 Names of company officers, board members, senior management team and other key personnel
M+M's company officers, board members, and senior management team are as follows:
• Officers: Antony Van Couvering, Fred Krueger .
Board Members: Antony Van Couvering, Fred Krueger.
• Senior Management: Antony Van Couvering (CEO); Peter Dengate Thrush (VP Policy); Elaine Pruis (VP Client Services); Brian Seidman (VP Corporate Development).
TLDH is managed by its executive Board members, as follows:
• Executive Chairman: Peter Dengate Thrush
• CEO: Antony Van Couvering
Chief Strategy Officer: Fred Krueger
e CFO: David deJongh Weill
Chief investment Officer: Guy Elliott
In addition, if chosen, we plan to hire a Miami-based senior management team dedicated to Dot Miami, as detailed in the answer to Question 2.4.10 and elsewhere.
1.2.4 Core competencies
M+M was formed in January 2009 specifically to provide registry services for new top-level domains. It is part of a family of companies majority owned by TLDH, with a commOn core senior management team supported by local expert staff. Our team has experience launching and managing dozens of top-level domains, and in particular in implementing solutions to respond to policy requirements. Our core competencies include:
• Technical operations of top-level domain registries, including implementation of policy via software.
• Top-level domain policy development, including use and abuse policies, complaint resolution procedures, community involvement, transparency and good governance best practices, and minimization and mitigation of abusive practices.
• Marketing and distribution of second-level domains, including thorough knowledge of registrar issues.
• Management of top-level domain governance issues in a global context, including extensive experience with ICANN, IGF, and other governance bodies.
, --, RFP 291270 j 4 Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI Entrepreneurial experience: our board members and senior management have collectively created over US$l billion in shareholder value
• Thorough knowledge and experience in intellectual property on the Internet, both from a legal perspective (UK, Commonwealth, and US jurisdictions in particular) and from a practical domain-name perspective from our experience operating TLD registries and ICANN-accredited registrars.
• Extensive contacts and relations with leaders in all aspects of the domain name ecosystem. Contacts include major figures in governance, both global and local; technical issues, including DNS, security, fraud prevention, hardware and software development, and standards development; marketing and distribution, including registrars, ad networks, and direct marketing; legal, including data protection and privacy, intellectual property, and policy development; financial, including major figures in banking, hedge funds, and venture capital.
1.2.5 Brief description of the company's business model, including percentage of total Of projected revenue derived from new gTLD-related work compared to other activities .
The business model of M+M is provide services to apply for, launch, operate, manage, and administer new top-level domains, both those applied for by TLDH and those of our clients. We expect that 100% of our projected revenues will come from gTLD-related work. The business model of TLDH is to invest in new gTLD opportunities, and, through its operating companies Minds and Machines LLC in the U.S., Minds and Machines Limited in the United Kingdom, and Minds and Machines GmbH in Germany - to assist new gTLD clients to apply for, launch, operate and manage new generiC top-level domains (gTLDs).
M+M provides new gTLD technical and consulting services .to its clients and to its affiliated companies. M+M, based in Santa Monica, will supplement and support the Miami-based staff dedicated to Dot MIAMI.
1.2.6 Location(s} ofcompany operations, including where operations serving dot MIAMI would be located
Our initial operations serving dot MIAMI are located at our Miami offices at 3301 N.E. 1st Avenue, Suite L307, Miami FL 33137, with support from our Santa Monica offices at 3100 Donald Douglas Loop North, Hangar 7, Santa Monica, CA 90405. If we are chosen to operate dot MIAMI, our staff will grow (see 2,10.4) and we will upgrade to new offices in Miami. Our sister company M+M has offices in Santa Monica, New York, and Seattle, Our German-based sister company, Minds and Machines GmbH, has offices in Berlin. In addition, TLDH board members maintain an
RFP 291270 Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI 5 office in Singapore, which is open to our use. The operations of dot MIAMI would be served primarily from the Miami and Santa Monica offices.
1.2.7 Length of time in business (and any relellant pre-establishment history). M+M was established in january 2009. TLDH was established in 2008. Members of the core management team common to all our affiliated companies (including the Chairman and CEO) have been involved in domain name businesses or organizations for more than ten years. Their relevant history is fully set out below in Section 1.3.
1.2.8 Any planned IPOs, mergers or acquisitions and/or company restructuring.
None.
1.2.9 Listings for publicly traded companies Top Level Domain Holdings Ltd, which wholly owns M+M, is listed under the ticker symbol TLDH on the AIM market of the London Stock Exchange.
1.3 Relevant Expertise
1.3.1 Experience in the TLD space.
We have both the ability and experience to fulfill the new gTLD requirements for dot MIAMI. We already operate an EPP registry service that meets ICANN's new gTLD compiiance standards. The registry's technical system is built to IETF standards, and currently powers the .FM TLD.
M+M was formed in 2009 for the single purpose of providing registry services for new gTLDs. Therefore, as a firm, our experience is necessarily limited. However, as a team, we have
v~ry deep experience in the areas covered by this question, and it is this experience we will cover here.
Members of our senior team have planned and executed multiple TLD launches and transitions. We have experience launching over 30 top-level domains, both gTLDs and ccTLDs. This has allowed us to establish deep and long-lasting relationships with registrars, major ISPs, software vendors, governmental actors, standards-setting bodies, law enforcement, and a host of other players peripherally (but importantly) involved in running a TLD. Our experience and contacts will be of great benefit for the launch and operation of dot MIAMI.
Registry Software. Espresso is based on CoCCA, a platform for ccTLDs, but further developed to be fully ICANN-compliant for new gTLDs. CoCCA powers over 35 ccTLDs today, and is the most widely distributed registry platform on the planet. Having been originally developed to meet
.. RFP 291270' 6 Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI the requirements of dozens of different governments and entrepreneurs, our registry platform is easily the most flexible and extensible on the market, and has been used and tested in a wide variety of conditions over many years. We have a secure, replicated and redundant operation, with excellent software support.
Management. Our management team is comprised of recognized leaders in the industry with extensive business and policy experience.
Peter Dengate Thrush, our Chairman was one of the leaders involved in the early days of InternetNZ, the New Zealand ccTLD. In the late 1990's he helped write the early policies for dotNZ, and developed the processes that led InternetNZ to become a model for ccTLD administration, widely copied globally. He served as Chair of InternetNZ from 1999 to 2001.
He served as Chair of the Asia Pacific Top Level Domain Associatio.n from 2003- 2007. In his term as Chair of the APTLD he helped build that organization from a volunteer secretariat to a fulltime CEO and staff, resulting in achieving increased membership targets, greater revenue and better services to members. APTLD is now a respected voice in the international Internet community. He has participated in multilateral negotiations, chaired meetings or given presentations in approximately 60 cities in 50 countries. He is internationally recognized as a leader in the Internet world.
Antony Van Couvering, our CEO, helped to launch .BT (BhutanL .PW (PalauL and .TM iTurkmenistan) as ccTLDs, and provided assistance to several other ccTLDs in both their launch and operational phases. As a registrar, he represented corporate clients in the launches of .info and .biz, resulting in a much higher rate of successful registrations than any of his competitors.
Mr. Van Couvering has worked with domain names and Internet infrastructure since 1996, and has had a substantial role in Internet governance and policy development throughout his career. He worked with Dr. Jon Postel, founder of the lANA, on a plan to restructure and revive the .US domain, elements of which were used in the eventual .US restructuring after Dr. Postel's death in 1998. In 1997 he formed NetNames in the u.s. (part of NetNames International, which operated both in the u.S. and Europe) and began working with major corporate clients to protect their intellectual property on the Internet.
He founded two companies, NetNames and NameEngine, which today form the backbone of two major providers of domain name services to corporate clie.nts. NetNames pioneered the business of corporate domain name services, which Mr. Van Couvering sold to NetBenefit, Group NBT (AIM: NBT). His second company in this area, NameEngine, which he sold to VeriSign (NASDAQ: VRSNL developed the concept of corporate domain name portfolios (it is now part of
RFP 291270 ···7 Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI Melbourne IT). He also founded a consumer domain name company, RegisterFREE, which was sold to Melbourne IT (A5X: MLB).
Among the clients he signed and worked with were: Adobe, American Express, Bridgestone-Firestone, CFSB, Chanel, Citibank, Coca-Cola, Colgate-Palmolive, Dell Computer, DLJ, Estee Lauder, Guerlain, Intel, Netscape, Paccar, Steinway, Viacom and many others. He also worked through a number of highly regarded IP law firms, including Brown Raysman, Fish and Richardson, Fross· Zelnick Lehrman lissu, Kenyon & Kenyon, McDermott Will & Emery, and White & Case.
Elaine Pruis, our VPof Client Services, has handled the launches and/or management of overa dozen ccTLDs over the last ten years, including:
e .AF (Afghanistan) - educated registrars and consumers on the registration system and TLD policies; supported day-to-day maintenance, operations, and provided support for registrars.
• .CM (Cameroon) - supported the launch and sunrise for trademark holders, and land-rush; provided training for hand-off of registry administrator.
o .ex, .. DMI 9HT, .1<1, .MU, .NF (Christmas Island Dominica, Haiti, Kiribatt Mauritius, Norfolk. Island) - supported the administration, operation and maintenance of registry operations for these ccTLDs .
.FM (Federated States of Micronesia) - oversaw the migration of .fm to the Espresso Platform. Migration was achieved over a one-week timeframe. Elaine currently manages the .FM technical operations and provides day-to-day support for the business administration team .
.GL, .GY, .MG, .MZ (Greenland, Guatemala, Guyana, Madagascar, Mozambique) provided a variety of services and levels of support for these ccTLDs.
• .PE (Peru) participated in the migration of .pe to a new registry platform. Demonstrated and marketed the registry software to the .pe CEO during their registry selection and advised on registrar relations.
• .5B (Solomon Islands) - supported all registry operations .
.TL (Timor L'Este, or East Timor) - handled the sunset of the old country-code name .TP, the migration of data to the new .TL, and transition of registry to new operators. The ,TP code was changed to .TL upon the independence of East Timor from Indonesia.
··.RF.P291270: 8 Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI 1.3.2 Experience in the ICANN community The senior members of our team have been involved with ICANN since its inception, and have been a significant force in shaping how ICANN works, the policies of Internet governance in general, and the specific rules for the new gTLD program.
We have studied and commented on every version of ICANN's Applicant Guidebook and have been involved in most of the working groups formed to create and amend the policies that are in the Guidebook. We understand the rules for creating names (and the exceptions to those rules), and we also understand the role of public comment, how ICANN determines whether two or more applications are considered to be in a "contention set," the strategies and tactics to employ in the case of contending generic terms, and the rules governing objections by communities, rights holders and governments.
Our very strong background in this area was streogthened in July 2011 when we were joined by the former Chair of ICANN, Peter Dengate Thrush.
Peter Dengate Thrush, our Chairman, was active during the founding of ICANN. From November 2007 until June 2011 he served as the Chair of the Board of Directors of ICAN N, and was a member of ICANN's Board for many years prior to serving as Chair, In his term, Internationalized Domains (IONs) were introduced, DNSSEC was introduced to the root, and the relationship between ICANN and the United States Government was fundamentally changed to increase the accountability and transparency of ICANN to the international Internet community. His network of contacts.• and understanding of the new gTLD process are unparalleled .
Mr. Dengate Thrush was one of the leaders involved in the early days of InternetNZ, the New Zealand ccTLD. In the late 1990's he helped write the early policies for dotNZ, and developed the processes that led InternetNZ to become a model for ccTLD administration, widely copied globally. He served as Chairof InternetNZ from 1999 to 2001.
He served as Chair of the Asia Pacific Top Level Doma in Association from 2003- 2007. In his term as Chair of the APTLD he helped build that organization from a volunteer secretariat to a fulltime CEO and staff, resulting in achieving increased membership targets, greater revenue and better services to members. APTLD is now a respected voice in the international Internet community. He has participated in multilateral negotiations, chaired meetings or given presentations in approximately 60 cities in 50 countries. He is internationally recognized as a leader in the Internet world.
Antony Van Couvering, our CEO, was one of the founders of ICANI\I and an important figure ih its early life, chairing the meeting that set up the different bodies within ICANN and establishing
. RFP291270 ····9 Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI the ground rules for decision-making that are still in place today. Hl= formed the International Association of Top Level Domains (IATLD) and in that role served as a member of the executive committee of the ccTLD organization within ICANN. He has remained active in ICANN as a regular contributor to policy development working groups and commentator with strong relationships at all levels of the organization.
lViost recently, he served on the working group that led to the abolition of the separation between registries and registrars in November 2010.
Elaine Pruis, our VP of Client Services, has been active in the ICANN community since 2003. While working for CoCCA, Elaine advocated for several ccTLD members in the CCNSO and represented members in working groups. Most recently Elaine was a part of the Joint Applicant Support working group, which over a two-year period, developed a multi-faceted support program for disadvantaged applicants. She Jed the "In-Kind Services" group. Her sub-group's recommendations were 100% adopted by the ALAC, GNSO, and ICAI\I[\! Board.
While all of our competition necessarily pay close attention to ICANN, and work within its structure, few if any have the experience, respect, depth of knowledge, and networks when it comes to this primary regulator of new gTLDs.
For dot IVIIAMI, we offer multiple advantages: clear and authoritative advice concerning ICANN; thorough understanding of the Applicant Guidebook and resultant likelihood of success with the ICANN application; early warning of any policy changes that might affect the dot MIAMI TLD, and skilled and respected advocacy for pOSitions and policies that matter.
1.4 Company Financial Information
1,4.1 What is your annual turnover
M+M is an operating company of Top Level Domain Holdings Ltd. (TLDH), of which it is a wholly owned subsidiary. TLqH is listed on the AIM ma rket of the London Stock Exchange (stock ticker TLDH), and was formed specifically to invest in and operate new top-level doma ins.
Since the mission of our company is to invest in and operate new gTLDs, and new gTLDs do not yet exist, we have small revenue compared to our expenses. Nonetheless, we have a strong cash position and are well prepared for the coming expansion of the domain name space. In November 2010 we raised $4.8 million, and last month in January 2012 we raised an additional
RFP 291270 10 Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI $14.2 million. 1 We have approximately $25 million in cash reserves as of the date of this writing, with no debt.
TLDH has a market capitalization of approximately US$67 million (42 million British pounds)2 OUl' ,last published financials, for the year ending October 2011,3 show an operating loss of £1.8 million on revenues of £54,000. For the year ending 31 October 2010, we lost £941,000 on revenues of £62,000. For the year ending 31 October 2009, we had revenues of £315,000 and a loss of £1.4 million. This last report starts the period since the company began its mission to invest in and operate new gTLDs. As a public company, our full financial records are open for inspection, and can be found on our website at http://www.tldh.org.
Our financial position is strengthened by the history and proven abilities of our principals. Members of the management of TLDH have raised over $200MM. in their careers and created over $1 billion in value with their previous companies. Fred Krueger, the principal shareholder and our Chief Strategy Officer, has created and sold eight companies to Viacom, Vivendi Universal, Macromedia (now Adobe) and others. Guy Elliott, our Chief Investment Officer, has had a very successful career creating companies working with natural resources. Antony Van Couvering, our CEO, founded and sold three domain name companies - to VeriSign, to Melbourne IT, to NetNames (now Group NBT). We are experienced and successful from a financial perspective and have every intention of repeating our past successes within TLDH.
1.4.2 What relevant insurance and indemnities do YOLl currently possess related to new TLDs/registry service provision and your potential partnership with the City of Miami. What is the limit of their liabilities? PLEASE SEE TRADE SECRETS COpy OF RESPONSE TO RFP
1.4.3 If requested subsequently will you provide your last three annual financial reports? Yes, although the operating history of M+M is less than three years. The financial results of our parent company, Top Level Domain Holdings, Ltd., are publicly available, as highlighted above in 1.4.1.
1 See http://www.tid h.org/2012/02/pl acing-to-raise-approximate ly-9-0-m ill ion/ 2 See http://www.lse.co.uk/SharePrice.asp ?SharePrice=tldh&goButton=Go! ,3 See http://www.tldh.org/wp-content!uploads/2009/04/TLDH_Ltd-October20llJI NAL.pdf
RFP291270 Informal Request for Proposals to Establish, Operate,and Administer dot MIAMI 11 1.5 Contracting Party
1.5.1 If awarded the contract, will you contract in your own right throughout the term of the contract? Yes.
1.5.2 If not, and you are acting as an agent for another entity, please give details of that entity and your authority to enter into a contract with the City of Miami on the entity's behalf.
Not applicable.
1.5.3 Detail which, if any, of your technical operations are carried out by third parties, identifying the firms, describing any SLAs you may have with them, any relevant liability insurance and your contingency plans in the case offailure. If you have ever experienced a significant failure by a service provider, please describe the issues, what steps you took and how the matter was resolved.
Two major functions of the technical operations are carried out by third parties: data escrow and DNS services, which includes both DNS and DNSSEe.
Data Escrow. ICANN requires data escrow via a 3,d_party provider. We have entered a long term arrangement with NCC Escrow International Limited (NCCL a respected provider of data escrow services listed on the London Stock Exchange.
Data escrow full and differential deposits will be submitted to our data escrow partner, NCC, according to the requirements detailed in Specification 2 of the registry contract in the Applicant Guidebook. The deposit schedule will be met, and each escrow deposit will match the specified format. The escrow files will be processed using compression and encryption, and will then will be signed, transferred and validated.
Our business contract with NCC requires that all ICANN-specified SLAs will be met by NCe. We have a contingency plan in place in case NCC fails to provide services according to the ICAN N required SLAs and our contracted agreement. Not only will we escrow the dot MIAMI data with NCC, we will also store copies of the escrow files in multiple locations. For every escrow deposit submitted to NCC, we will store a duplicate copy of that escrow deposit on our local servers and at our secondary NOe. If NCC fails to escrow the data we will have an exact copy available for use as necessary.
DNS and DNSSEe. We contract with Packet Clearing House (PCH) for DNS services. PCH is the industry leader in DNS, evidenced by their creation and early implementation of anycast, as well as the invention and use of many other security and stability evolutions in DNS
RFP 291270· Informai Request for Proposais to Establish, Operate; and Administer dot M.IAMI technology. PCH has been operating production anycast for TLDs and in-critical infrastructure
in-addrs since 1997, with 100%' up-time over more than 14 years. PCH operates the world IS largest, oldest, and most continuously-available anycast server cloud. PCH first hosted the production anycasting of a root nameserver in 2002 and has built or designed many of the other large anycast clouds on contract. PCH servers are used to provide ccTLD, root DNS, and in addr DNS slave service, and supports IDN requirements.
PCH is responsible for the construction and support of more than a third of the world's approximately 350 Internet Exchange Points (lXPs). They provide leading global TLD DNSSEC key management and signing infrastructure. PCH's anycast DNS nameservers system operates with approximately 50 locations on six continents.
PCH has positive working relationships with lANA, root operators, and other DNS providers. TCP and UDP RTI Service Level Requirements have been, and will continue to be, met. PCH's expertise and robustness far exceeds the ICANN requirements for DNS..
Highlights of the PCH DNS implementation include:
A highly robust global anycast network; Proven track record of 100% DNS uptime; • Fully compliant with all RFCs including 1034, 1035, 1101, 1982, 2181, 2182, 2671, 3226,3596,3597,3901,4343,4472,5155; • Full DNSSEC capability and support;
e Experience mitigating DDCS attacks; IDN support • IPv6 capable with IPv4-IPv6 dual stacks at nodes; Diverse DNS node announcement strategy • Compliant with Specification 6 and aillCANN policies.
All DNS service parameters, including DNSSEC proper resolution, will be met through the utilization of PCH's DNS system, a world-renowned, industry leader in the DNS field. PCH is the only DNS provider to commercially offer Level 4 DNSSEC, the highest possible security level, which is utilized for the root servers.
[For the remaining part of our answer to this question, please see the trade-secrets copy of our response.]
RFP 291270 Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI 13 2 Technical & operational capacity, experience and approach
2.1 Project and Relationship Management
2.1.1 Please supply two examples {no more than 500 words each} ofsuccessful partnerships or business relationships you have been part of to deliver large, complex projects or programs.
Example 1: Migration of the .FM Top Level Domain
One large and complex project that we handled was the migration of .FM from an archaic database system to the new gTLD-compliant EPP Shared Registry System (SRS), now branded by us as Espresso. Elaine Pruis, VP of Client Services for M+M, led the project and remains responsible for overall.FM registry network operations.
The .FM registry is well known for supporting innovative on-line radio entertainment. Play.FM, Last.FlVI, Ping.FM and Turntable.FM are just a few of many successful businesses operating under the .FM TLD. It is the go-to TLD for Internet radio, music, media and broadcasting. In 2011, BRS Media, the .FlVI administrative arm, was named by Inc. Magazine as one of the fastest-growing private companies for an astonishing fourth year in a row. In addition, BRS Media ranked in the list of Top 75 Media Companies that featured prominent companies such as Pandora, FriendFinder and Demand Media. This is a high-profile, innovative, and demanding domain space that requires utmost stability, responsive support, and a back-end registry operator that is flexible and able to stay ahead of the technology curve.
We won the .FM contract in 2010, whereupon we built out a dedicated NOe in Los Angeles at One Wilshire, the world's most connected data center.
The NOe requires complex hardware systems including load balancers, switches, servers, and monitoring equipment. All of the gear was specified and purchased within two weeks of the decision to move the registry to the LA NOC. An expert Network Architecture Engineer was flown in from Australia to create the initial registry environment and train our staff on configuration and operations.
More than 200 Registrars were informed ofthe upcoming transition through an email campaign and weekly conference call updates. The migration was planned so that the end customer would see no loss of service, and were completely unaffected by the move.
Once all of the equipment was networked, the operating systems had been installed, and every part proven stable, the SRS was installed. The SRS operated with dummy data and was thoroughly tested over a week1s time. During that period the .FIVI legacy data was cleaned up
Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI and massaged to cleanly import at the end of the testing stage. When all systems were verified
and the engineers signed off on the migrationr it was coordinated with the. registrars that the registry service would be unavailable for the planned window. The registry data was then moved from the old system to the new system. The DNS service was redirected to the new. FM I IP range, the SRS services started, and new zone files were propagating within a few hours. All parties involved in the migration vigorously tested and closely monitored the live production system for a 24 hour window. A high-alert state was continued for two weeks but no problems occurred.
The migration was considered to be flawless, and the .FM registry continues to operate in a stable, responsive manner today. Registration volumes have increased 15% since we took over operations of the registry.
Example 2: New gTLD Implementation
The development of the new gTLD program is an example of a complex and ultimately successful project. The ICANN Board was led throughout this period by Peter Dengate Thrush, our current Chairman. A brief description of some of the many parties involved in this multi stakeholder process is given below.
ICANN~s Generic Names Support Organisation (IIGNSOII) began in 2005 to develop a policy for the introduction of new gTLDS, following two pilot expansion rounds in 2000 and 2003/4. In July 2007, a final report was published, and after further public comment it was passed to the Board for action.
The policy decisions had been made the Board's task was implementation. The Board first asked ICANN staff or whether itcould be implemented, and the staff responded with a series of papers on individual topics. Based on these the Board discussed concerns relating to geographic names, non-L1'Itin scripts, and thorny issues of public order and morality, until in Paris in June 2008 the Board adopted the policy and asked staff to deliver a final implementation programme. Few realized at that historic vote that it would be three further years before implementation would be reached.
There followed a series of eight versions of the Applicant Guidebooks - a process by which staff took GNSO policy work, public comment, and specialist research papers, and developed the rules by which new gTLDs would be added to the Internet.
The Intellectual Property Constituency ("IPC"), a member of the GNSO, played an active, challenging role in this process. IPC had agreed in principle to the GNSO Final Report, but still questioned whether new gTLDs were useful.
RFP 291270 Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI 15 In an effort to bridge this gap, Board members suggested in March 2009 that a specialist trademark team develop IP protection mechanisms that would be acceptable to the whole community. The IPC formed such a team, which led to a series of enhanced trade mark protections.
Another major partner in the process was the Governmental Advisory Committee ("GAC"). Once it became clear that the Board were not going to accept all of the GAC positions, a formal correspondence began to seek compromise. This set the scene for some historic face-to-face negotiations between the Board and the GAC, commencing in February 2011 and continuing right through to the Singapore meeting in June 2011,
Peter Dengate Thrush, our Executive Chairman, worked on these (and other) issues, leading staff and the Board to implementable decisions out of the competing interests and views of the IPC, the GNSO council, the GAC, the registries and the registrars. This included keeping the Board focused and productive through hours of additional and extended meetings, encouraging staff to produce thousands of pages of reports, papers, minutes and updates, chairing public debates and public sessions, media interviews and debates. It meant working with each of the partners mentioned, in ,often heated and adversarial conditions. On 21 June 2011 the Board adopted an implementation scheme for the introduction of new gTLDs according to the GNSO policy.
2.1.2 Please explain your approach to creating and maintaining good and profitable working relationships with the City of Miami and dot MIAMI stakeholders
[For our answer to this question, please see the trade-secrets copy of our response.]
2.2 ICAN N Application
2.2.1, Describe in no more than 1500 words how you will manage the dot MIAMI application in partnership with the City of Miami, including but not limited to:
2.2.1.1 Application planning and timeline to ensure a timely and complete application
ICANN requires that an applicant for a new generic top-level domain (gTLD) demonstrate a high level of technical knowledge, financial stability, business acumen, and an understanding of the policy framework under which a top-level domain must be operated and administered. A gTLD is a critical piece of Internet infrastructure, and the manager of a gTLD must serve its registrants, its contractual partners (such as ICANN and any contracted registrarsL and the global Internet community generally.
The essential spirit of gTLD management is that of service to its constituents, first enshrined in the domain name industry's founding document, RFC 1591, written in 1994, which says:
... RFP 291270 Informal Request for Proposals to Establish, Operate, and Administer dot MIAMi Concerns about IIrights" and "ownership" of domains are inappropriate. It is appropriate to be concerned about "responsibilities" and "service" to the conununity... 4
Approached from this perspective, the requirements of the ICAI'\IN Applicant Guidebook are logical and straightforward. They require that the applicant understand its responsibilities and has the resources and a plan to fulfill them.
We have been deeply involved as volunteers at ICANN in the six years of development of the policies that shaped, and now comprise, the Applicant Guidebook, and have an excellent understanding not only of the questions themselves, but the reasoning behind them. We are fully confident that any application we are involved with will be accurate, complete, and will pass all evaluations.
The ICANN application has 50 questions, which can be broadly divided into four categories:
• Questions about the applicant Questions about the applicant's mission, and the policies necessary to accomplish that mission • Questions about the applicant's technical infrastructure • Questions about the applicant's financial capabilities and its understanding of business processes
[For the remaining part of our answer to this question, please see the trade-secrets copy of our response.]
2.2.1.2 Elaborating the purpose of the TLD for the City of Miami
We believe much of the work has been done on defining the purpose in the preparations made by the City of Miami to date, in order to have issued a detailed RFP.
From our own discussions with the City of Miami it is clear that dot MIAMI is intended to provide an Internet "home" for people and activities with a flMiami" focus, specifically for marketing Miami activities, businesses and people, and in a way that will raise funds to further promote those activities. Dot Miami will be badge of pride and origin for those activities.
[For the remaining part of our answer to this question, please see the trade-secrets copy of our response.]
2.2.1.3 Consultation with relevant stakeholders on key strategy policy issues
The RFC defines the relevant stakeholders as including "business, including ICT players, registrants and intellectual property rights-holders; civil society including relevant human rights
4 See www.ietf.org/rfc/rfc1591.txt
.. -- , RFP291270 Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI 17 advocates; local and national government; [and] law enforcement." To these stakeholders we would add local community groups.
[For the remaining part of our answer to this question) please see the trade-secrets copy of our response.)
2.2.1.4 Elaboration of business model and plan Our management team is intimately familiar with the finances of a TLD operation, and with the ICANN application requirements. We will build and submit to the City of Miami with the draft application a business plan sufficiently detailed to satisfy the ICANN requirements) in particular the internal consistency and Continuing Operations Instrument requirements.
2.2.1.5 Development of required policies and procedures We have comprehensive documented policies on all of the issues raised in the application, many of them derived from our years of experience in operating TLDs in a variety of policy environments around the world. As a result of that experience, they have been thoroughly "road tested" under operational condition. An overall policy framework (to be modified as required) is attached as Attacnment 2.9.1. We will be able to adapt these policies readily to any special conditions applying in the dot MIAMI environment after consultations with the Stakeholder Advisory Group, and in the implementation and operations phases. After delegation, .we will be able to develop policies covering Sunrise, Landrush, auction and other matters whose precise details are not required for the ICANN application.
2.2.1.6 Preparing and submitting all application documentation on behalf of the City of Miami through the ICANN TLD Application System
Our companies have been purpose-buiftto attend to the requirements of the ICANN application system. Our team members have been intimately involved in the development of these systems, and monitor them for changes. We are in communication with ICANN staff on the technicalities of use of their submission system. We will prepare and submit all documentation through the . . ICANN system in a compliant and timely way.
2.2.1.7 Support of the City of Miami throughout the entire evaluation process
[For our answer to this question) please see the trade-secrets copy of our response.]
2.2.1.8 Management of any objections or contentions
[Fo'r our answer to this question, please see the trade-secrets copy of our response.]
2.2.1.9 How would you keep the City of Miami and stakeholders informed
[For our answer to this question, please see the trade-secrets copy of our response.]
RFP291270 18 Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI 2.3 TLD Capability and Capacity
2.3.1 Please give an overview of your overall technical and operational capacit}1 relevant to TLD ·operations. We have the ability and experience to manage the dot MIAMI TlD. We already operates an EPP shared registry service, "Espresso," which meets ICANN's new gTLD compliance standards. The Espresso platform is based on the CoCCA SRS, which currently powers more than 35 TLDs. Espresso's technical registry system is built to IETF standards, and is currently used by us to operate the .FM TLD. This same system will be used as prototype for building the dot MIAM I dedicated SRS.
Our back end registry, Espresso, provides critical registry services plus customary administrative functions:
Receipt of data from registrars concerning registration of domain names and name servers through IETF RFC compliant EPP, known as the Shared Registry System (SRS), and through 11 GUI, offering both a Production Environment and an Operational and Testing Environment,
Dissemination ofTLD zone files (DNS),
• Dissemination of contact or other information concerning . domain name registrations (RDDS, also known as "Whois"),
• Ability to support and maintain Internationalized Domain Names (IDNs),
• DNS Security Extensions (DNSSEC),
• IPv6 and IPv4, compliant with Specification 6 of the registry contract in the Applicant Guidebook,
• Standard ICANN reporting,
• Primary and Secondary SRS are in geographically diverse locations, and
• Bulk domain import and transfer functionality.
The Registry system receives data from registrars, writes the data to the database, and disseminates TLD zone files to DNS services. The registry has an RDDS function so that contact and domain registration information may be retrieved through a publicly available web page. RDDS updates are dynamic, and DNS zone files are updated according to the schedule established for the particular TLD. The registry zone servers hold the master zone files, and are verified with DNSSEC. The EPPinterface, RDDS servers, and DNS servers are all fully RFC
. RFP29i270 Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI compliant, as required by ICANN. The Registry system leverages anycast technology for DNS. The SRS supports both IPv4 and IPv6 NS entries.
The registry system also automates required monthly reports to ICANN, and builds escrow data files in accordance with ICANN's requirements. We supply an Operational and Testing Environment (OTE) for registrar use, and more than 200 registrars are already connected to our platform. With a large number of the most popular registrars already technically integrated, the burden of going to market is significantly lessened compared to a registry that must la unch from scratch and integrate registrars prior to the launch phase.
Additional services included in the Registry services are Internationalized Domain Names, Reporting, Registrar Billing, Registrar Support, and Sunrise and Trademark Clearinghouse services. All of these services conform to the new gTLD requirements, and are currently in use for the operation of the .FM TLD. The Registry system is scalable, and thus can accommodate the increase on service demands that growth in the dot MIAMI TLD will bring.
2.3.2 How do you meet Specification 6 of the Applicant Guidebook (on interoperabiJity, continuity, and performance) and all relevant JETF RFCs?
We will meet the requirements of Specification 6 "Registry Interoperability And Continuity Specifications" while operating dot MIAMI by utilizing Espresso, our registry platform. We have a history of providing a highly reliable and robust domain name registry services to the global community of registrars, registrants, and Internet users. The registry operates on a state-of-the art platform that has been proven to be secure, reliable, and robust. The registry infrastructure is specifically designed to handle the high transaction volumes found in the TLD registry business. The EPP interface, RDDS servers, and DNS servers are all fully RFC compliant, as required by ICANN.
In addition to the core registry services, the registry system provides a comprehensive billing and reporting solution, data escrow services, and full Internationalized Domain Name (lDN) support. Services are backed by a 24x7 help desk and network operations center.
[For the remaining part of our answer to this question, please see the trade-secrets copy of our response.]
'RFP29i2iO 20 Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI 2.4 TLD Expertise
2.4.1 Please provide details of your key personnel and proposed subcontractors) knowledge and experience of technical, operational and business plans for new TLDs, referencing the requirements ofthe ICANN Applicant Guidebook (no more than 500 words).
We have assembled an exceptionallv strong team with extensive experience operating, administering, maintaining and marketing TLDs. Even beyond our experience in registry operations detailed in other parts of this proposal, we believe that our experience in dealing with customers directly sets us apart and is of critical importance in the success of the dot MIAMI registry. Our experience as registrars, who deal directly with domain name customers, gives us a special insight into how to promote, market, price and position dot MIAMI domain names.
Our team's experience includes:
• The acquisition of the delegations of several TLDs • Providing technical infrastructure Training registrars and consumers on the use of the registrations system Policy creation and education • Day-to-day registry maintenance and operations Registrar relations and support lVIarketing TLD launches • Sunrise and Landrush • Migration and Transitions of legacy registries Business Development Software development
We also have extensive experience in marketing gTLDs and in dealing with customer issues. As hundreds of new gTLDs come online, registry operations will increasingly include what were formerly registrar issues, as consumers increasingly look directly to registries for solutions to their problems. Informed observers agree that the line between registrars and registries will become increasingly blurred as registries realize they cannot rely on registrars for marketing in a world where registries outnumber registrars, and ICANN increasingly loosens the restrictions on the sale of domains directly by registries.
Our experience with top-level domains extends beyond ICANN-regulated gTLDs, such as .info, .com, .and net, to ccTLDs, such as .fm, .CX, .gs, and many others. While ccTLDs are not required to comply with ICANN consensus policies, the underlying infrastructure for gTLDs and , Inf~;mal:eq~est for p;oposal~t:':::~~:;7~;:'r~te, and Administer dO:-f~ I~;~ I" .. -.. --" -·'--2·t·.. - ccTLDs is nearly identical, and ccHDs generally look to the Internet Engineering Task Force (I to applicable Requests for Comments (RFC) and to ICANN's Internet Assigned Numbers Authority (lANA) for guidance and best practices. ccHDs are often the source of new technical and policy ideas that after the proper policy process end up as ICANN consensus policies. ccHOs are also much closer to their customers because often they operate without registrars as intermediaries. Our experience with ccTLOs is therefore very relevant to the dot MIAMI launch and management.
The primary operational difference between ccTLDs and gTLOs is the direct involvement of local governments in the former. We believe that our experience in working with governments and understanding their imperatives, which are often very different from the commercial/policy imperatives of ICANN, is relevant and helpful to working with the City of Miami. It has also affected the design of the Espresso software which can handle the complicated rules and verification procedures demanded by the many ccTLDs that it serves.
2.4.2 Give details of nDs you operate, or have operated, Dr are iikely to operate in the future.
Members of our team have operated and provided a broad range of services to several TLDs with diverse business models over a lengthy timeline. The following timeline indicates which HOs were under management, the nature of the operational role, and in some cases a summary of the technical and financial performance. Most ccHD registration numbers are not published and are considered proprietary. Instead we note the general health of the TLD. We also discuss the SRS and policy development, as our staff have been instrumental in building the policy framework and SRS to its current state. Following the timeline is a quick-view table displaying the entire list of TLOs that have been under our management.
2.4.2.1 Dates of operation
Past Operations.
2002 Elaine Pruis provides customer, registrar, and development support for the .cx registry. The .cx registry operates on a legacy API registry system. A helpdesk ticketing system, FAQ, and development tracking tool is implemented.
2003 The registry administrators of .cx, .gs, and .nf work together to develop a Shared Registry System (SRS) API for a standardized platform. This stand·ardization removes barriers registrars face in offering smaller ccTLDs to their customers. Registrars are now able to more easily offer these TLDs to their existing customer base, and several registrars gain new customers.
...... "'-2·' RW-291270' 2 Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI The Council of Country Code Administrators is formed to provide resources for ccTLD operators as a service to the community. CoCCA is a not for profit member owned organization that shares. technology, policy, and ICANN liaison services. Ms. Pruis' support role expands to serving all CoCCA members.
Under the advice of the Office of the Domain Name Commissioner (NZ) and also drawing on the co.uk policy, an Acceptable Use Policy framework is developed.
In order to protect communities from cybercrime and intellectual Property Rights infringements, the AUP is made available to the entire ccTLD community.
Dominica, .dm, implements the SRS API on a local NOe. Ms Pruis travels to Dominica to provide on-site training of the registry system to local staff and administrators. A registrar tool is developed, allowing legacy domains that had been registered directly with the registry office to be technically managed by the TLD administrator.
2004 - Further development of the AUP occurs. As a show of support, multiple ccTLDs adopt the policy framework even though they are using other back-end registry providers.
PDNS (Power DNS) is offered to registrants as a hosting option.
After the name of the country changes, the .tp code is sunsetted, and all domains are then matched to the new country code, .tl. The .tl registry is migrated to the SRS platform and administered by Ms. Pruis.
2005 - Mauritius, .mu, is migrated to the CoCCA Shared Registry System. Ms. Pruis provides local training, technical support to the local operators, and periodically manages the registrar and customer support when the local operators vacation or take family leave. Namibia, .na, migrates to the CoCCA Registry System. Registrars are informed of the change in technical platform and supported during the transition
An EPP Shared Registry System is developed in response to International Engineering Task Force (lETF) best practice recommendations. Further development of the software in order to support IPV6 occurs. The standardization and stability of the EPP technical platform ushers in a new era of world-wide sales for previously obscure TLDs.
2006 - A Complaint Resolution Service for members is developed, where violations of AUP are initially reviewed at no cost. An Ombudsperson works to mediate disputes that are not in clear violation of the AU P. The CRS is a much less expensive alternative to the WIPO UDRP process of settling domain disputes. A Panel of Experts is formed to rule on disputes that are not resolved
RFP 291270 Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI 23 ; I
I i· I amicably by the Ombudsperson. A new Ombudsperson for mediation is appointed at the end of the year.
Ms. Pruis presents the Harmonised AUP model at the domainers industry conference "Domain Round Table" as an example of best practice policy. Those operators using the policy framework are noted as seeking to responsibly promote the domain name space.
Afghanistan, .af implements CoCCA registry system. All .af domain records are migrated to the SRS and registrars are supported through the technical change, as well as after the .af TLD begins operating on the SRS. South Georgia a nd Sandwich Islands, .gs migrate from the previous operator, Adams Names, to the SRS. The .gs administrators work closely with Ms. Pruis, who maintains the technical operations and provides registrar support. Kiribati, .ki implements the SRS. Their data is migrated to the SRS, and Ms. Pruis provides operational and registrar support for .ki.
A template Registrar Accreditation Agreement is created, harmonizing registry acceS5 policy. The RAA removes legal department delays by allowing registrars to complete only one agreement that enables access to all member ceTLDs. Network Solutions, as well as dozens more Registrar companies, integrates with the new EPP Registry System. Several new TLD members migrate legacy data to the fully developed EPP SRS. Registrars are now able to connect to a single portal and offer multiple ccTLDs to their registrants. Eighty-one registrars are integrated with the SRS.
Registration volumes steadily increase. As the TLDs on the SRS become more prevalent and therefore, more visible, credit card fraud becomes an issue. The registrar storefront that is offered as part of the SRS package is overhauled to aid administrators in curbing and preventing credit card fraud. TLDs using the SRS get a reputation for cracking down on cybercrime as soon as it pops up, so bad actors move on to other TLDs.
A centralized helpdesk with FAQs is implemented for the increasing number of members in order to lighten the customer service load, and several registry business functions are implemented to ease management, including: reporting, black lists for prohibited names, auto mailing for notifications, and internal DNS for In-zone hosts.
2007 - VeriSign becomes an accredited registrar and offers to their customers member ccTlDs. Dozens more registrars are accredited in order to offer for sale domains on the SRS. Multiple layers of security such as IP restrictions are put in place and enforced. Registrars are required to use second-factor security tokens in order to access the Registry system. One Hund red twenty three registrars are integrat~d with the SRS.
RFP 291270 Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI Mongolia, .mn, adopts the best practice policy framework; Heard and McDonald Island, .hm, joins CoCCA.
Because of the broad variety of TlDs now operating the SRS, development to support variable commercial models occurs. The software now supports payments via wire, credit card, over the counter, or a line of credit, enabling administrators to choose the payment system that works best with their business model. The software is fUlther developed to support ENUM and Internationalized Domain Names, IDNs. Several new features are added to the SRS for users, including transaction receipts and deleted domain history.
Members report that UDRP is expensive and a complex way to address some local issues, so further development of the Complaint Resolution policy occurs. The goal of the policy regime is to have a free Dispute Resolution System under a .single environment to resolve complaints and introduce amicable dispute resolution.
Ms. Pruis presents the SRS model at the lACTLD meeting in Venezuela, signing up latin American members. The SRS is presented by Ms. Pruis at the ccTlD Tech day during the los Angeles ICANN meeting. The system is installed on a laptop and 40,000 domain registrations are taken during aone-hour session.
The SRS is offered on Sourceforge as an open-source registry solution. Members may now run the system on their own servers in their own countries. This flexibility enables registries with' the necessary expertise to implement a world-class EPP registry system in-country without the development costs. This service to the community enables resources and jobs to stay within the homeland.
58. Solomon Islands, migrates to the SRS away from AusRegistry. Afghanistan, .af, is no longer supported on the SRS as internal strife has made zone upgrades unreliable.
::W08 - Peru, .pe implements the registry system in-country. Ms. Pruis assists with training and migration support, and continues to provide ICANN liaison services for .pe after the transition is fully complete. Guatemala, .gt, and Mozambique, .mz become members and are supported in their use of shared resources. Haiti, .ht, Montserrat, .ms, Guyana, .gy, and Nigeria, .ng implement the SRS tool in-country. Palau, .pw, joins CoCCA.
GLOCOM, Japanese academic institutes, and some international partners use the AUP framework in a study of governance of Pacific Island ccTlDs. The project helps ccTLDs establish , policies to cut down on phishing and spamrriing.
~RFP291270' Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI The software is developed to make WHOIS (RODS) disclosures modifiable in support of variant privacy laws. Fourteen different language files are added to the registry tool so users may manage domains in their native language .
. Ms. Pruis presents the SRS at the Paris ICANN meeting to prospective new gTLD appiicants and to the 180 Registrars are now integrated with the system.
2009 - CoCCA offers exclusive licensing agreement to M+M for use of the SRS in the gTLD space, M+M provides "Capacity Building Grants" to CoCCA for development and training. "Espresso," the gTLD registry system based on the CoCCA SRS, is launched. CoCCA members upgrade to Espresso CC (country code). Espresso CC development is funded by M+M, seeking through our capacity building program to ensure that Espresso remains the most widely deployed and "field tested" TLD registry system in use today .
.ECO and .Radio applicants select M+M for registry services. Madagascar, .mgi installs and operates Espresso CC in-country. Federation of Micronesia, .fm, migrates to hosted version of Espresso Cc. Cameroon, .cm implements the Espresso CC system in-country.
Additional security features are added to block Conficker and other malicious DNS behavior. The gTLD life cycle is now supported in Espresso CC, and gTLD required reporting functions and escrow tools are added. DNSSEC is tested and implemented.
ENOM completes Registrar Accreditation bring the number of accredited registrars offering member TLDs to 226.
2010 - Development of the SRS software to meet new gTLD requirements continues. The .FM registry is migrated to a dedicat.ed NOC and operations are completely taken over by M+M.
2011 - The .fm registration volumes increase 15% from October 2010- October 2011, due to a very stable technical platform, and increased targeted marketing.
Several new gTLD applicants contract with M+M for registry services. Our senior staff 'are present at every key ICANN and GAC meeting, ensuring our client's positions are heard by decision makers.
TLD Description Team Experience
.af Afghanistan From 2006-2008, when .af became fully operational, Elaine Pruis educated registrars and consumers on the registration system and
RFP 291270 26 Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI TLD Description Team Experience
TLD policies; supported day-to-day maintenance,. operations, and provided support for registrars.
.as American Antony Van Couvering and employees helped Samoa local residents acquire the original delegation for .as and provided technical infrastructure and marketing. From 2006-2009, Elaine Pruis advised the delegated operator on registry systems.
.bt Bhutan Antony Van Couvering helped local· residents acquire the original deiegation for .bt and supported the launch of the .bt domain on behalf of the Bhutan government.
.cm Cameroon Elaine Pruis supported the launch and sunrise for trademark holders, land-rush; a nd provided training for complete operational hand-off to the registry administrator. 2008- 2009.
.C)( Christmas Elaine Pruis supported the administration, Island operation . and maintenance of registry
operations for .C)( from 2002-2010 .
.dm, .ht, .ki, .mu, .nf Dominica, . Elaine Pruis supported the administration, Haiti, Kiribati, operation and maintenance of registry Mauritius, operations for .dm from 2003-2008, .ht 2008· Norfolk 2010, .ki 206-2010, .mu 2005-22010, and .nf Island 2003-2010.
.fm Federated Elaine Pruis oversaw the migration of .fm to States of the Espresso Platform. Migration was achieved .Micronesia over a very short timeframe. The .fm registry is
j{F'P 291:270- Informal Request for Proposals to Establish, Operate, and Administer dot M lAM I TLD Description Team Experience
currently operated by M+M. 2009-current
.eg, .gl, .gs, .gt, .gy, .mg, .mz Egypt, Elaine Pruis provided an array of registry Greenland, services and multiple levels of operational Guatemala, support for the following TLDs: .eg 2007 Guyana, 2009, .gl 2009-2010, .gt 2008-2010, .gs 2004· Madagascar, 2010, gy 2008·2010, .mg 2009, and .mz during Mozambique 2008.
.pe Peru Elaine Pruis demonstrated and marketed the SRS to the .pe CEO during their registry selection process, participated in the migration of .pe to the SRS, and advised on. registrar relations. 2007·2010.
.pw Palau Antony Van Couvering helped local residents acquire the original delegation for .pw and provided technica I infrastructure.
.sb Solomon Elaine Pruis supported all registry operations Islands for .sbafter it migrated away from AusRegistry from 2006-2010.
.tl Timor L'Este Elaine Pruis assisted with the sunset of .tp, the migration of data to .tl, and the tra nsition of the registry to new operators. The .tl code was changed to .tp upon the independence of East Timor from Indonesia. 2004-2010
.tm Turkmenistan Antony Van Couvering acquired the original delegation and launched, marketed, and operated .tm
Various Antony Van Couvering oversaw marketing and software development .for VeriSign's Digital
RFP 291270 28 Informal Request -(or Proposals to Establish, Operate, and Administer dot MIAMI TLD Description Team Experience
Brand Management division from 2001 to 2004, which handled domain names for major - brand holders in all ccTLDs. He regularly advised ccTlOs on policy matters.
[For the remaining part of our answer to this question, please see the trade-secrets copy of our response.]
2.4.2.2 The nature of your role (i.e., overall registry operation or registry service provision)
See responses to question 2.4.2 and 2.4.3 for details of the work and services performed.
2.4.2.3 Summary of technical performance, including anv downtime Because of the large number of registries that we have operated, we simply note that with the advent of the EPP SRS, technical performance in the TlOs we have operated became very reliable and stable. Downtime was generally limited to the SRS being off-line during regular monthly maintenance windows, where no domain change orders could be processed. None of the TLDs we have operated ever experienced any DNS downtime (where domain names were unable to resolve on the internet).
2.4.2.4 Summary of financial performance, including registration numbers and changes overtime [For our answer to this question, please see the trade-secrets copy of our response.]
2.4.3 Do you have any experience operating or providing relevant services to a registry operating a closed or verified registrant service (no more than 250 words)? No, although members of our team have worked extensively as a registrar to registries with closed or verified-registrant registries. As detailed below in 2.4.3.1, we are aware of many of the methods employed by closed registries; we have had to comply with them in our work as registrars.
2.4.3.1 Describe your approach to managing registrant pre-verification or authenticatioh if dot MIAMI were to require registrants [to be] located in the Greater Miami area. Please include methodology and estimated costs, if available.
[For our answer to this question, please see the trade-secrets copy of our response.]
--RFP 291270· Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI 2.4.4 Can you provide the required registry services according to the ICANN Applicant Guidebook and draft registry agreement? Please summarize capabilities and, if you outsource any service to a third party, please name the organization.
[For our answer to this question, please see the trade-secrets copy of our response.]
2.4.5 Please summarize your approach tD providing registry services to dot MIAMI, including:
2.4.5.1 Receiving registration and name server data from registrars
Espresso, our Shared Registry System (SRS), is an EPP-protocol compliant registry with a server/client API and a web-based graphical user interface (GUll. The Espresso registry platform is based on the CoCCA SRS, which currently powers more than 35 TLDs, but updated extensively during 2009 - 2011 to be fully ICANN-compliant. The Espresso registry platform is currently used by the .FM TLO and provides services to nearly all ICANN-accredited registrars who make up 95% of the total gTLD market share. The registry infrastructure is specifically designed to handle the high transaction volumes found in the TLD registry business. The EPP interface is fully RFC compliant, as required by ICANN.
As well as our two-year experience with .FM, our staff has over seven years of experience operating EPP-based registries using CoCCA, a ccTLD-specific version of Espresso, This experience includes working with, and developing relations with, all major ICANN-accredited registrars.
[For the remaining part of our answer to this question, please see the trade-secrets copy of our response.]
2.4.5.2 Giving registrars zone server status updates
Registrars are given confirmation of domain change orders through EPP polling messages, and TLD zone files are updated when new registrar orders are written to the database. The zone files are then uploaded from the database to the TLO master server, and finally distributed through the ONS to slave servers that help end users resolve the whereabouts of the new or modified domain name.
In addition, Specification 4 of the ICANN registry agreement requires that the Registry operator must allow any qualified Internet user (including registrars) with which it enters into agreement access to zone file data. We will allow such user to access the designated Internet host server and download zone file data using the file format described in Section 2.1.4 of Specification 4.
-RFP'29i'270 .. 30 Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI 2.4.5.3 Disseminating the zone files
[For our answer to this question, please see the trade-secrets copy of our response.]
2.4.5.4 Operating registry DNS servers
We contract with Packet Clearing House for DNS services. Highlights of the PCH DNS implementation include:
• A highly robust global anycast network,
Proven track record of 100% DNS uptime,
• Fully compliant with all RFCs including 1034, 1035, 1101, 1982, 2181, 2182, 2671, 3226,3596,3597,3901,4343,4472,5155,
• Full DNSSEC capability and support, including DNSSEC Level 4 (we are the only registry service provider able to offer, this level of security)
Experience mitigating DDOS attacks,
IDN support,
• IPv6 capable with IPv4-IPv6 dual stacks at nodes,
• Diverse DNS node announcement strategy,
• Compliant with Specification 6 and alilCANN policies.
[For the remaining part of our answer to this question, please see the trade-secrets copy of our response.]
2.4.5.5 Disseminating contact and other information regarding domain name server registrations
We have operated the RDDS for .FM since August, 2010. Our RDDS system is easily capable of , handling the daily peak volume queries required by ICANN SLAs. The, domain name data is displayed according to the guidelines in Specification 4 of ICANN's registry agreement.
[For the remaining part of our answer to this question, please see the trade-secrets copy of our response.]
.. -RFp·29:t-270- Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI 2.4.5.6 Any other required services according to the Applicant Guidebook or draft registry agreement.
Escrow
In addition to archiving all daily TLD zone files, we meet the data escrow requirements by implementing ICANN's required data escrow regime. Proper data escrow arrangements are outlined and adhered to in order to prevent the loss of registry data. We ensure that data escrow implementation is performed in a manner which:
• Protects against data loss, • Follows industry best practices, Ensures easy, accurate and timely retrieval and restore capability in the event of a hardware failure, and Minimizes the impact of software or business failure.
[For the remaining part of our answer to this question, please see the trade-secrets copy of our response.]
2.S IPv6
2.5.1 IPv6 - What is your methodology and current status on a transitioning to IPv6?
Every applicable component of our system, architecture and infrastructure has full IPv6 connectivity.
The Espresso platform is fully IPv6-enabled, with no sole reliance on the public IPv4 network. It is, however, still able to resolve IPv4 traffic. All components of the registration system fully support IPv6 addressing. • Primary name servers will return results for both IPv4 and IPv6 records (both AAAA glue and A6 records are possible). Backup DNS resolution servers are also IPv6-enabled and are able to provide services via both IPv6 and IPv4. • Name servers listed within the anycast network will answer authoritatively for both IPv4 and IPv6 addresses within the dot MIAMI domain.
[For this portion of our answer to this question, please see the trade-secrets copy of our response.]
Our software first began accepting IPv6 data (AAAA IP information for hosts) in 2006 in several of the ccTlD registries using the SRS software.
'~RFP2912'70 . .... -......
Informal Request for Proposals '(0 Establish, Operate, and Administer dot MlAM I 2.5.2 Haw waulcl you support IPv6-enabled services jor dot fIIIlAMI registronts and related services? [For our answer to this question, please see the trade-secrets copy of our response.]
2.6 Security and Stability
. 2.6.1 Describe, in no more than 1000 words, your organization's own injormation and network security arrangements, including:
2.6.1.1 Access control
[For our answel' to this question, please see the trade-secrets copy of our response.]
2.6.1.2 Capacity to withstand brute force and other types of attack
[For our answer to this question, please see the trade-secrets copy of OUI' response.]
2.6.1.3 Incident mitigation and response
[For our answer to this question, please see the trade-secrets copy of our response.]
2.6.1.4 How dot IVIIAMI registry services would be maintained in an attack on it or on other parts of your infrastructure
[For our answer to this question, please see the trade-secrets copy of our response.]
2.6.2 Describe how you will meet the security and stability requirements required in the Applicant Guidebook. [For our answer to this question, please see the trade-secrets copy of our response.]
2.7 Data Protection and Law Enforcement Access
2.7.1 Please demonstrate your ability to store and process all personal data, including registration data, in compliance with United States (U.S.) data protection legislation
Data protection in the United States concerning the Internet can be divided into three categories: (a) private commercial relationships; (b) governmental and law enforcement access; and (c) private legal rights enforcement. Private commercial rules concerning consumer data protection are, other than with respect to children, self-regulatory and based on Federal Trade Commission (FTC) best practice guidelines. Governmental and law enforcement and private .third-party access to personal data are covered by a number of laws designed to balance the constitutional rights of Internet users with the legitimate needs of governmental and law
··RFF"291270 Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI enforcement actors t.o pursue civil and criminal prosecutions and the legitimate needs of private third-parties to protect their rights.
Private Commercial Self-Regulation.
ICANN will contractually require that domain registration data, which qualifies as personal data, be made publicly available by dot MIAMI through the Whois system. The Whois system is akin to a public phone book that allows anyone connected to the Internet to view the name, add ress, and email contact information of the owner of a domain name, as well as information about the administrative and technical contacts, name server address information and DNS security s status.
In addition, as the entities who interact with and provide services to the public, ICANN accredited registrars who contract with us to sell dot MIAMI names will collect personal data from end users and transfer it to the dot MIAMI registry, which will store the data (registrars . , may also store the data for the purposes of providing customer service to their customers}.
We understand our responsibilities with respect to the collection and storage of personal data entrusted to us and our registrars by registrants, particularly the understand ing that our handling of personal data, and the handling of personal data by third parties, must accord 'With the best practice recommendations of the FTC.
The FTC has set forth principles that responsible companies should follow in their collection, handling and storage of end-user personal information. These principles are: (1) Notice/Awareness; (2) Choice/Consent; (3) Access/Participation; (4) Integrity/Security; and (5) 6 Enforcement/Redress. We will adhere to these principles as discussed below;
• Notice / Awareness. The most fundamental principle is notice. Consumers should be given notice of an entity's information practices before any personal information is collected from them. Without notice, a consumer cannot make an informed decision as to whether and to what extent to disclose personal information. Moreover, three of the other principles discussed below choice/consent, access/participation,' and enforcement/redress -- are only meaningful when a consumer has notice of an entity's policies, and his or her rights with respect thereto.
5 See "Specification 4, Specification for Registration Data Publication Services," New GTLD Agreement Specifications, ICANN gTLD Application Guidebook, September 19, 2011. 6 Feder,al Trade Commission, "Fair Information Practice Principles," http://www.ftc.gov!reports!privacy3ifairinfo.shtm#Fair%2Olnformation%20Practice%20Principles%20Ge nerally
Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI While the scope and content of notice will depend on the entity's substantive information practices, notice of some or all of the following have been recognized as essential to ensuring that consumers are properly informed before divulging personal information:
o identification of the entity collecting the data;
o identification of the uses to which the data will be put;
o identification of any potential recipients of the data;
o the nature of the data collected and the means by which it is collected if not obvious (passively, by means of electronic monitoring, or actively, by asking the consumer to provide the information);
o whether the provision of the requested data is voluntary or required, and the consequences of a refusal to provide the requested information); and
o the steps taken by the data collector to ensure the confidentiality, integrity and quality of the data.
Choice / Consent. The second widely-accepted core principle of fair information practice is consumer choice or consent. Specifically, choice relates to secondary uses of information i.e., uses beyond those necessary to complete the contemplated transaction. Such secondary uses can be internal, such as plaCing the consumer on the collecting company's mailing list in order to market additional products or promotions, or external, such as the transfer of information to third parties.
• Access / Participation. Access is the third core principle. It refers to an individual's ability both to access data about him or herself -- i.e., to view the data in an entity's files -- and to contest that data's accuracy and completeness. Both are essential to ensuring that data are accurate and complete. To be meaningful, access must encompass timely and inexpensive access to data, a simple means for contesting inaccurate or incomplete data, a mechanism by which the data collector can verify the information, and the means by which corrections and/or consumer objections can be added to the data file and sent to all data recipients.
• Integrity / Security. The fourth widely accepted principle is that data be accurate and secure, To assure data integrity, collectors must take reasonable steps, such as using only reputable sources of data and cross-referencing data against mUltiple sources, providing consumer access to data, and destroying untimely data or converting it to anonymous form. Security involves both managerial and technical measures to protect against loss and the unauthorized access, destruction, use, or disclosure of the data. Managerial measures include internal organizational
'RFP291no Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI measures that limit access to data and ensure that those individuals with access do not utilize the data for unauthorized purposes. Technical security measures to prevent unauthorized access include encryption in the transmission and storage of data; limits on access through use of passwords; and the storage of data on. secure servers or computers that are inaccessible by modem.
• Enforcement/Redress. Finally, government enforcement of fair "'information practices, by means of civil or criminal penalties, is a third means of enforcement. Fair information practice codes have called for some government enforcement, leaving open the question of the scope and extent of such powers. Whether enforcement is civil or criminal likely will depend on the nature of the data at issue and the violation committed.
In the United States the protection of personal data in the online consumer context is self regulatory. Thus, we have .developed policies and practices with respect to our and our registrars coliection, storage and use of personal data to ensure compliance with the FTC's best practices.
• Processing Dota Foirly and Lowfully. The collection and use of personal data by the dot MIAMI registry and its registrars is required by ICANN in connection with the sale or transfer of a domain name. The use of personal data by dot MIAMI will be limited to publishing it in the Whois database as required by ICANN. In addition to personal data, registrars will collect financial information - e.g. credit card or banking personal data - to effectuate sales of dot MIAMI domain names and to service a registrant's account. Whereas Whois personal data is made publicly available by dot MIAMI, we will require via the dot MIAMI Registry-Registrar agreement that additional information collected by registrars will not be publicly available and will be securely stored, used only for the intended purpose of servicing the registrants account, and accessible to the registrant via password protection .. dot MIAMI and its registrars will provide easily accessible and understandable notice on their websites of why personal data and information is required to be collected and stored and made publicly available via the Whois database; how their other personal information - e.g. credit card or banking personal data will be handled, secured and processed; dot MIAMI's and the registrar's responsibilities with respect to such personal data under the FTC best practices guidelines; and the registrants rights. Registrants will have to knowingly consent to such use and handling of their personal information in order to purchase a dot MIAMI domain name.
o Processing Personal Data for Specific Purposes. The persona I data Will on Iy be processed for the following specific purposes: publication via the Whois system; by
RFP'291270-:: Informal Request for Proposais to Establish, Operate, and Administer dot MiAMi a registrar to service a registrant's account; transfer to the ICANN-mandated data escrow agent; and l in the event of an ICANN requestl transfer from the data escrow agent to ICAI\JN itself.
• The Amount of Data Held. The amount of data held will be the minimal amount of data required for use in the Whois system, and required by registrars to sell and service registrants' accounts.
• Keeping Personal Data Accurate and Up To Date. Registrars are required by lCANN to inform registrants at least once a year that they should access their Whois information and make any updates necessary. In addition, dot MIAMl/s registrars will be contractually required to allow registrants to easily review and make changes to the personal data he Id by the registrar.
• Retaining Personal Data. dot MIAMI will retain personal data for no longer than
required by ICANN I and registrars will be required via the. Registry-Registrar Agreement to do the same. ICAi\IN requires that registries and registrars retain personal data upon the non-renewal of a domain name for the grace period established bythe registry according to ICANN consensus policies. ICANN/s rules are designed to protect registrants who may have forgotten to renew their domain names and might otherwise lose them. Dot Miami will require its registrars to delete/destroy any and all registrant personal data immediately upon the end of any applicable grace period.
• The Rights of Individuals. Dot MIAMI and its registrars (via contract) will prominently advise registrants of their rights pursuant to these policiesl and provide efficient online and other means for registrants to access their data, object to processing if it causes unwarranted and substantial damage or distress, opt out of direct marketingl obtain information concerning actions taken by automatic means, and correct inaccurate data.
• Information Security. Though the Whois system is a publicly available databasel ensuring that the information contained within the database is secure and accessible only to authorized individuals is vital. dot MIAMI will employ industry best-practice security measures to ensure that the Whois database is as secure as possible from criminal or other inappropriate access. In additionl dot MIAMI will only enter into registrar agreements with registrars who employ industry best practice.security measures with respect to personal data and customer records.
• In the event that any federal (e.g. The Commercial Privacy Bill of Rights Act, introduced by Senators Kerry and McCain) or applicable Florida laws concerning personal data protection and privacy are enacted, we and our registrars will enact
.. ".c_. - _~··"."·c---·- ~-'.-'~..-.-."." ..'--,,--- -"".7-.-··"'~'.'~~RFP'291~2'70'-~
Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI policies to the extent required to comply with such laws, though we believe that our present data collection and use policies- already meet the spirit of such proposed laws).
In addition to the foregoing, we will fully comply with, and our registrars will be contractually required to comply with, the provisions of Florida Statutes Title XLVI, Chapter 817, § 817.5681 "Breach of security concerning confidential personal information in third-party possession; administrative penalties," requiring that we provide notice to Florida resident registrants in the event that we or one of our registrars suffers a data breach involving unencrypted data (we note that all dot MIAMI personal data stored by us will be encrypted).
2.7.2 What, if any, are the implications of your data escrow provision for compliance with u.s. data protection? All data that is required to be placed in escrow pursuant to ICANN's regulations will be deposited with NCC Group, a leading data escrow service prOVider, at one of its secure data escrow facilities in the United States, and NCC will, to the extent permitted by ICANN poiicies, be contractual required to follow the best practice guidelines promulgated by the FTC as more fully discussed above.
2.7.3 What provisions have been/would be made for u.s. lawful access to registration and other types of data by u.s. authorities? What provisions have been/would be made for takedown or other lawful enforcement actions by legally entitled entities? 1. Lawful access to registration and other types of data by US authorities. Access to personal and other data stored in the dot Miami registry will be made available to governmental_ and law enforcement actors in accordance with federal, state and local laws concerning the production of documents and records. We will comply with any lawful order to produce such records issued by a federal, state or local court or other governmental actor with appropriate authority and jurisdiction.
2. Takedowns and other lawful enforcement actions by legally entitled entities. Even before implementing post-registration processes for takedown or other lawful enforcement actions, rights holders have access to certain ICANN mandated protection mechanisms:
a. As part of the new gTLD system, ICANN will be instituting a Trademark Clearinghouse (TCH) service in which all new gTLDs are required to participate. Under the TCH system, trademarl< holders register their trademarks with the TCH, which validates them and inserts them in the TCH '
'38 Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI database. All new gTLDs registries will be required to use the TCH to provide ICANN-mandated rights-protection mechanisms (the UDRP, URS, Clnd Trademark Claims Service).
b. Dot Miami will implement an ICANN-mandated Sunrise period, to occur after delegation of dot MIAMI into the Internet root, and prior to general availability of second-level domains under dot MIAMI. During the Sunrise period, trademark holders have the right to purchase their trademark as a second-level domain name under the dot MIAMI top-level domain.
After the delegation of a second-level domain name, rights holders have access to the administrative procedures and notification systems to assist them in combatting abusive or illegal registrations. ICANN requires that new gTLD registries comply with the following dispute resolution mechanisms (or any other Consensus Policy that may be adopted by ICANN from time to time):
c. The Uniform Rapid Suspension System (URS). The URS is an ICANN mandated process that allows trademark holders to quickly have an infringing site taken down by showing their legal right to such trademarked name.
d. The Uniform Dispute Resolution Service (UDRP). The UDRP is another ICANN-mandated' process under which a trademark holder can seek to assert their rights to a domain name. Unlike the U RS, the U DRP is designed to handle trademark claims that are not as clear cut, where, for example, there are two distinct individuals who own the same trademark in different classes.
e. Trademark Claims Service. ICANN requires that all new gTLD registries operate a Trademarl< Claims service, whereby the registry {by way of ICANN accredited registrars} provides notice to potential registrants of existing trademark rights at the time of registration, and in addition provides notice to trademark owners of relevant names registered.
[For the remaining part of our answer to this question, please see the trade-secrets copy of our response.]
. RFp c2912:78· Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI 2.7.4 If you envisage data processing or hosting outside the U.s., what provisions are in place to prevent risks to the operation of dot MIAMI or increase its legal liability because of access or enforcement actions by other legal authorities or other entities? [For our answer to this question, please see the trade-secrets copy of our response.]
2.8 Accounting and Reporting
2.8.1 Will you provide correct and timely reporting - on registration volume and trends, operational, technical and financial performance - and billing for dot MIAMI? Please briefly describe, include frequency and provide sampJe reports. We will provide correct and timely reporting. Our registry software can be configured to create reports from any of the data in the database. It is possible to export data for every single registry transaction that occurs, no matter how small: the number of reports we can provide is virtually unlimited.
Reports on financials, object creation, edits, deletions, changes, transfers, database maintenance, RDDS queries, EPP logs, access by IP address and many other reports are available. Every action from log-in to deletions is stored and available for reporting. All object records may be exported for reporting.
[For the remaining part of our answer to this question, please see the trade-secrets copy of our response.]
2.9 Policy Development
2.9.1 Describe your capability and experience in developing registry policies and procedures, including:
2.9.1.1 Registration and use policies
In response to Question 1.3 above, we discussed the policy development experience of Elaine' Pruis, whose experience in this aspect of registry operations bears repeating: from 2001 to 2009 she managed the domain registry syst'em for the Council of Country Code Administrators (CoCCA), which provides technical registry and policy services to hundreds of registrars and over 30 ccTLDs. Elaine is a veteran of TLD policy development, educating registrars and consumers on the registration system and TLD policies, TLD launches, TLD migrations and registry operations. Elaine worked with .af (Afghanistan), .cm (Cameroon), .dm (Dominica), .ht (Haiti), .ki (Kiribati), . mu (Mauritius), .nf (Norfolk Island), .sb (Solomon Islands) and .tl (East Timor), where, among other services, she helped develop a policy framework including implementation of dispute resolution, acceptable use, and complaint resolution systems.
"'"4'"0-"- "-"'"'' --"'''''''_'''_'' ..... -" "···_,,····,,··,,·_"' ..··,,--,,RFp..29l2-70 Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI We referred also to the experience of Peter Dengate Thrush in .NZ and with the Asia Pacific Association of country code managers, and of Antony VanCouvering with .BT (BhutanL .PW (Palaul, .TM (TurkmenistanL and with IATLD, Together, this group has unparalleled experience of TLDregistration, use and other policies and implementation of them.
[For the remaining part of our answer to this question, please see the trade-secrets copy of our response.]
2.9.1.2 Whois, rights protection and abuse policies (regarding Who is, describe and demonstrate experience developing an effective Whois policy and set of procedures that comply with both I(ANN requirements and U.S. data protection law),
Whois policy is largely set by ICANN, and so our relation to Whois policy is to comply with it rather than develop it. We note again that we already operate an EPP registry service that meets ICANN's new gTLD compliance standards. The ,registry's technical system is built to IETF standards, and currently providing service to the .FM TLD. Espresso, our back-end registry, service platform, provides critical registry services plus customary administrative functions, including dissemination of contact or other information concerning domain name registrations
(RDDS, ICANN's technical term fo~ Whois). Our staff has years of experience operating thick registries in the ccTLD space, and our RDDS has been designed from the ground up for thick data display. We are also capable of complying with and supporting any replacement RODS technologies sanctioned by ICANN.
Our RDDS/Whois service:
• is fully compliant with all relevant RFCs including RFC 3912; • represents each data object as a set of key/value pairs as defined by Specification 4 of the proposed registry agreement in the Applicant Guidebook; • is production tested, highly flexible and scalable, with a track record of 100% availability; • exceeds current performance specifications supporting dynamic updates; • is geographically distributed ,sites to provide greater stability and performance; • protects RODS data from data mining using proven technologies; and • provides additional search capabilities (e.g. IDN, registrant data).
Our existing RODS solution is distributed, flexible, scalable, and stable; with a proven history of real- time dynamic updating, with no outages. Its design and construction is agnostic with regard to data display policy: it is flexible enough to accommodate thick or modifjed thick models, or indeed, any potential future ICANN policy (such as different information display levels based on user categorization).
RFPc291-2:70 Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI As required by the Application Guide Book, RODS responses will be displayed in a consistent format. Additionally, all fields will be fully compliant with all applicable EPP mappings as specified in RFCs 5730-5734.
Accordingly we are already compliant with ICANN's technical Whois requirements.
Opportunities for additional policy development in this area occur in the ICANN arena. They have historically included debate on whether a registry should have a "thick" Whois (containing data about registrants and other data) or "thin" (containing only sufficient data to allow registration and resolvability, with all substantive data including such as billing information, registrant phone numbers, held by the registrar). For new gTLDs, all registries are obliged under the new gTLD rules to operate ."thick" registries, so that debate is rendered moot. A remaining area of interest is the rules under which access may be made to zone file and Whois data by whom, at what rate, under what conditions. For these and other open questions, we have experience in developing rules that both meet local need and meet local legislative and other rules.
We are confident that with our experience in operating a registry that is fully compliant with . ICANN requirements in relation to Whois, and with our understanding of the legal framework and the responsibilities under that of registries and registra rs under contract.
[For the remaining part of our answer to this question, please see the trade-secrets copy of our response.]
2.9.1.3 Escrow, failover, and registry continuity
Escrow policy is set by ICANN, so again our job is to comply with it. A little more latitude is granted with regard to failover and registry continuity, and in the cases where ICANN is not definitive, we will follow industry best-practice recommendations. Among the registry services we already provide routinely are data escrow (via NCC Group), failover procedures, and registry continuity planning. All of these services conform to the new gTLD requirements, and are currently in use for the operation of the .FM registry.
[For our answer to this question, please see the trade-secrets copy of our response.J
2.9.1.4 Sunrise /Iand rush /Iaunch strategy and policies
[For our answer to this question, please see the trade-secrets copy of our response.]
.. ·R~.p·291..270-..·--····.. ---..·---- ..-· .. - ...- ...... -_.--. ..-... -- .... - --- - Informal Kequest for Proposals to Establish, Operate, and Administer dot MIAMI 2.9.1.5 Internationalized domain names (at the second level) Members of our staff have implemented IONs in a number of ccTLO registries, including "dotMasr," the Arabic-script ION ccTLO for Egypt, in conjunction with the National Telecom Regulatory Authority of Egypt. We are fully familiar with the RFC's, I(ANN policies and procedures concerning IONs, and can configure the Espresso registry platform to accommodate all available IDN scripts. ION policy development is quite specialized it is much more than deciding which alphabets or scripts to support. We look forward to working with the City of Miami in establishing an ION policy and to implementing it.
2.9.2 Please outline your strategy and approach to developing policy in collaboration with the City ofMiami and relevant stakeholders, including, but not limited to: , 2.9.2.1 Business, including leT players, registrants and intellectual property rights holders
[For our answer to this question, please see the trade-secrets copy of our response.]
2.9.2.2 Civil society including relevant human rights advocates
[For our answer to this question, please see the trade-secrets copy of our response.]
2.9.2.3 Local and national government
[For our answer to this question, please see the trade-secrets copy of our response.]
2,9,2.4 Law enforcement
[For our answer to this question, please see the trade-secrets copy of our response.]
2.10 Customer Support
2.10.1 What your customer support capabilities?
We have the capabilities to support each type of customer for dot MIAMI. See our answer to 2,10.2 below for a discussion of the types of dot MIAMI customers, and 2,10.3 for the capabilities required,
2.10.2 What customer support needs do you envision dot MIAMI may have?
[For our answerto this question, please see the trade-secrets copy of our response.]
2.10.3 What operational and support resources and personnel do you envision/would you make available for supporting dot MIAMI registrants and registrars? Where would they be based?
[For our answer to this question, please see the trade-secrets copy of our response.]
. RI~~.2,9.J270 Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI 2.10.4 If your proposal is successful, do you have any plans to locate personnel in Miami? If so, how many and [what] would their roles be?
[For our answer to this question, please see the trade-secrets copy of our response.]
l.ll Human Resources
2.11.1 How many full-time emplo}Iees does your organization employ? How many ful/· time contractors/freelancers does your organization engage? Please include a copy of your organizational chart.
[For our answer to this question, please see the trade-secrets copy of our response.]
2.11.2 What type of team will be assigned to this project? What will each person's role be?
[For our answer to this question, please see the trade-secrets copy of our response.]
2.11.3 How many employees or full time contractors/freelancers would be working direct/}/on this contract? For how long?
[For our answer to this question, please see the trade-secrets copy of our response.]
2.11.4 Briefly describe the percentage of your staff that would work on this project relative to your entire staff (including full time contractors/free lancers).
[For our answer to this question, please see the trade-secrets copy of our response.]
2.11.5 Please provide details on the personnel'and any proposed subcontractors who would wor/( on this contract, describing their skills, background and qualifications, and key responsibilities.
[For our answerio this question, please see the trade-secrets copy of our response.]
2.11.6 How many gTLD applications do you plan to support in total during the first five years of the proposed partnership with the City of Miami? How will you ensure the dot MIAMI application, delegation and management are given proper support?
[For our answer to this question, please see the trade-secrets copy of our response.]
2.11.7 How many, if any, Miami-based jobs would be directly created by your proposal?
[For our answer to this question, please see the trade-secrets copy of our response.]
RFP 291270 Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI 2.11.8 How would you maximize interactions with Miami-based businesses for the procurement of products and services? [For our answerto this question, please see the trade-secrets copy of our response.]
2.12 Marketing
2.12.1 Describe your organization's TLD marketing experience and expertise (no more than 500 words).
Members of our team have run multiple successful domain name businesses/ including top-level domains. We are experienced in marketing to large brands (important for the Sunrise period), to registrars, and to consumers. As with dot MIAMI, the marketing was multi-faceted, including advertising, trade shows/ word-of-mouth and via registrars and influencers.
In her- work at CoCCA, Elaine Pruis attended many meetings of ccTLD administrators and through her patient outreach helped grow CoCCA into the most widely-deployed registry system on the planet, taking customers away from Afilias/ AusRegistry, and other competitors. She did this as CoCCA's single representative, against the competition's formidable marketing and sales staffs. Her relations with registrars (she was also CoCCA's only customer service representative) annually increased registrations for CoCCA members beyond the general growth trend· and above their expectations.
Antony Van Couvering created three domain name companies from scratch and sold them to established public companies. NetNames was sold to NetBenefit (now Group NBT); NameEngine was sold to VeriSign; and RegisterFREE was sold to Melbourne IT. The first two companies were specialized in helping large corporations manage their intellectual property (Le./ domain names) across all the ccTLDs, while RegisterFREE was the largest pre-ICANN consumer registrar, pioneering what became the registrar model.
NetNames and NameEngine succeeded by providing timely, actionable, intelligent information to intellectual property lawyers by means of seminars, publications, telephone conferences, and participation in industry trade shows. In each case, these companies captured the lion's share of the market (after NetNames, he noticed that the existing companies were not providing what customers wanted, so he created NameEngine). RegisterFREE succeeded by making it very easy to register a domain name, and doing providing the service for a fraction of the cost of competitors.
[For the remaining part of our answer to this question, please see the trade-secrets copy ofour response.]
.RF-P29127.0...... _ Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI 2.12.2 What is your approach to marketing the dot MIAMI TLD? Please include indications of expected registration volume in the first five years of operation, and an overview market analysis. [For our answer to this question, please see the trade-secrets copy of our response.]
2.12.3 How would you work with existing registrar channels in the U.S. to maximize dot MIAMI registrations? Please describe your existing relationships with U.S. based or focused registrars. [For the prior part of our answer to this question, please see the trade-secrets copy of our response.]
In her work at CoCCA, Elaine Pruis attended many meetings of ccTLD administrators and through her patient outreach helped grow CoCCA into the most widely-deployed registry system on the planet, taking customers away from Afiliasl AusRegistry, and other competitors. She did this as CoCCA's only representative, against the competition's formidable marketing and sales. staffs. Her relations with registrars annually increased registrations for CoCCA members beyond the general growth trend and above their expectations.
Antony Van Couvering created three domain name companies from scratch and sold them to established public companies. NetNames was sold to NetBenefit (now Group NBT); NameEngine was sold to VerlSign; and RegisterFREE was sold to Melbourne IT. The first two companies were specialized in helping large corporations manage their intellectual property (i.e., domain names) across all the ccTLDs, while RegisterFREE was the largest pre-ICANN consumer registrarl pioneering what became the registrar model.
NetNames and NameEngine succeeded by providing timely, actionable, intelligent information to intellectual property lawyers by means of seminars, publicationsl telephone conferences, and partiCipation in industry trade shows. In each easel these companies captured the lion/s share of the market. RegisterFREE succeeded by making it very easy to register a domain name, and by providing the service for a fraction of the cost of competitors.
[For the remaining part of our answer to this question, please see the trade-secrets copy of our response.]
...... RF.P2912Z0~ ...... Informal Request for Proposals to Establish, Operate, and Administer dot M lAM I 2.13 Compliance
2.13.1 Describe your experience in effecting compliance with registration and use/abuse policies and balancing registrant rights with thaseof, for example, intellectual property rights-holders. (No more than 500 words.) Our experience in effecting compliance with Registration and Acceptable Use Policies is deep. We have many years of experience operating and maintaining registries, have written a widely adopted Acceptable Use Polic\' framework that is now in use by several TLDs, and firmly believe in the value of the "thick" registry model. A strong Acceptable Use Policy combined with effective monitoring, a complaint resolution process, and regular scanning and analysis of registry data enables us to run a successful program t.o combat various forms of abuse.
[For the remaining part of our answer to this question, please see the trade-secrets copy of our response.]
2.13.2 Describe your experience in preventing or minimizing domain mime warehousing and cyber~squatting. (No more than 500 words.) Cybersquatting and warehousing are different evils of the domain name system. Cybersquatting means registering a name in bad faith that by right belongs to another; warehousing means registering a name that doesn't belong to anyone else, and then holding it without using it in the hopes of selling it later. The first is illegal; the second is simply detrimental to users and especially to a top-level domain, because valuable names that people naturally navigate to are empty, or contain a hated "parking page." Both of these practices are relatively uncommon outside of .com because of its dominance and what is known as "natural traffic," or the propensity of users to simply type ".com" at the end of a word. I\lonethel,ess, both of these phenomen'a are likely to occur in dot MIAMI.
A great deal of time has been spent at ICANN trying to combat cybersquatting, and members of our team have worked hard in helping to come up with policies. As Chair of ICANN, our Chairman Peter Dengate Thrush helped form the Independent Review Team (made up of trademark lawyers) to suggest mechanisms to combat cybersquatting. In response, they added to the existing UDRP mechanism the new Uniform Rapid Suspension (URS) and Trademarks Claims Service have given trademark owners a very impressive toolkit to combat these ills in all new gTLDs, including dot MIAMI.
[For the remaining part of our answer to this question, please see the trade-secrets copy of our response.]
Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI 2.13.3 How would you ensure compliance with dot MIAMI's policies and procedures (No more than 500 words.)
[For our answer to this question, please see the trade-secrets copy of our response.]
2.14 Transitioning
2.14.1 Have you ever trans;tioned out of managing or operating a TLD, or as a registry service provider?
We have experience successfully transitioning "in" legacy TLD registries ranging from complete, well-formatted data and zone files to defunct, mismanaged, and inconsistent data sets. Though we have migrated many TLDs "in" to our SRS, We have never lost the business of a TLD and had to migrate data "out," but we are fully capable of cooperatively migrating a transitory TLD data to a new operator. Because of our strong project management capabilities, we have been able to migrate entire registries over a weekend with only a few hours of actual SRS downtime, and with uninterrupted DNS resolution. We have a strong history of cooperative collaboration during registry migrations.
Our key staff members have been involved with several registry transitions, some with complete data, some with partial or archaic data. Our SRS is built to easily import and export data that is in ICANN's required Escrow format, easing the migration effort and significantly reducing the time required to transition the data.
As an example, in August 2010, we migrated the .FM technical registry operations from the legacy back-end operator to our registry platform and NOC. This was a cooperative migration, where both parties worked together to ensure a quick changeover. First, a registry transition plan was mapped out. The next step was building out the M+M NOC to ensure the SRS was capable of managing the traffic and able to scale with the growth of the registry. Registrars, were given notice of the impending change, a timeline, and new support contact details. The TLD was configured in the gaining SRS, and a thorough review of the system architecture, TLD configuration, DNS, and RDDS occurred. Next, the data was cleaned up and imported to the database of the idle gaining registry. The losing registry stopped services, and the SRS was brought up on the Mind + Machines US NOC. The system was monitored for stability, and support lines were open for registrars. The transition was fully successful and there were no connectivity problems for registrars. The registry has operated and grown in a stable and secure manner on the Espresso platform.
Our staff has participated in several other migrations, including:
. Informal RequesT for Proposals to Establish, Operate, and Administer dot MIAMI • Migrated .AF from a legacy database system to an EPP SRS, educated registrars and
consumers on the registration system and TLD policies; supported day-to~day maintenance, operations, and provided support for registrars.
• Migrated .CM from a legacy database system to an EPP SRS, supported the launch, sunrise and land-rush; provided training for hand-off to new registry administrator.
• Migrated .CX, .DM, .HT, .1<1, .MU, .NF from legacy database systems to an EPP SRS, and supported the administration, operation and maintenance cif registry operations for these ccTlOs, and registrar support.
• Participated in the migration of .PE to a new registry platform. Demonstrated and marketed the registry software to the .PE CEO during their registry selection and advised on registrar relations.
• Handled the sunset of the old country-code name .TP, the migration of data to the new .TL, and transition of registry to new operators. The.TP code was changed to .TL upon the independence of East Timor from Indonesia. Supported the administration,. operation and maintenance of registry operations and registrar for .TP.
Our team has extensive experience in transitioning registries. Our technical manager, Elaine Pruis, has been instrumental in assisting several TlO registry operators during re-delegation of administrative operations,as historically many ccTlOs were run out-of-country and recently these governments applied to lANA and gained delegation of the registry operations. When a re delegation of the registry becomes official a migration of data must occur. Policies are revamped and quite often commercial models are modified.
[For the remaining part of our answer to this question, please see the trade-secrets copy of our response.]
2.14.2 If so, please describe how you successfully transitioned out.
As noted in 2~14.1, we have never lost the business of a registry and therefore have not had to transition a TlO out of our management.
3 Financial Proposal
The City of Miami is committed to the success of dot MIAMI, and will assist with marketing, advertising, and PR on an as-needed basis to maximize revenues and ensure the TLD is a commercial success. The City of Miami is open to sharing the rewards with the partner for zero. to little out of pocket costs for the City of Miami.
..... RFP29-f270'"
Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI Regarding financing the application and operation of dot MIAMI, the Successful Proposer shall be required to pay the ICANN application fee of US$185,OOO on behalf of the City of Miami. The City of Miami will support the marketing, communications, resources, and the City of Miami's legal fees, on an as-needed basis and as negotiated between the parties.
Bearing in mind the variety of potential business models for dot MIAMI, we wish to receive financial proposals from potential partners including detailed arrangements for the first five years of:
Cash flow provided by proposer Registry service provision by proposer Revenue-sharing to the City of Miami and proposer Any other economic/financial advantages to the City of Miami
3.1.1 What will the cost ofsetting up the registry be? Please include detailed financial information. Please include any third-party provision or fees (e.g., DrvS service, data escrow).
[For our answer to this question, please see the trade-secrets copy of our response.]
3.1.2 What is the expected annual cost to your organization of operating the registry? Is this a fixed or per-domain cost? Please include detailed financial information. Please include any third-party provision or fees (e.g., DNS service, data escrow).
[For our answer to this question, please see the trade-secrets copy of our response.]
3.1.3 Describe your organization's overall capacity to operate dot MIAMI on a self financed basis.
[For our answer to this question, please see the trade-secrets copy of our response.]
3.1.4 Can you provide sufficient startup capital to establish and operate dot MIAMI for its first five years, including: Sufficient cash flow to fund operations during an estimated pre-launch period ofsix month and for the first five years? Proposals that combine ready cash flow with financial arrangements such as letters of credit will be considered.
[For our answer to this question, please see the trade-secrets copy of our response.].
3.1.5 How do you plan to recoup your investment? By when? Describe your proposed revenue-shoring arrangement and timeline.
[For our answer to this question, please see the trade-secrets copy of our response.1
RFP 291270 Informai Request for Proposals to Establish, Operate, and Administer dot MIAMI 3.1.6 Please provide projected registration and financial performance projections, including optimistic, worse, and expected returns, including impact on proposed revenue share.
[For our answer to this question, please see the trade-secrets copy of our response.]
3.1.7 What is your financial position and understanding regarding the City of Miami's position if the application to ICANN for dot MIAMI is unsuccessful?
[For our answer tothis question, please see the trade-secrets copy of our response.]
3.2 Alternative Financial Proposal
If you wish to propose an alternative financial proposal regarding investment and revenue sharing, please do so. Please describe it fully and clearly state the advantages. It is also recommended that you clearly mark your alternative proposal 113.2 Alternative Financial Proposal" and also submit a financial proposal against the requirement in section 3.1. .
[For our answer to this question, please see the trade-secrets copy of our response.]
4 Other Questions
4.1 Other Information
4.1.1 /s there any other information you would like to include that will help us assess you as a partner and in particular any information you are'aware of and which has not been disclosed elsewhere which could have a significant adverse impact on:
4.1.1.1 The reputation of the City of Miami'
No.
4.1.1.2 The RFP respondent's ability to satisfy the requirement of this RFP now or in the future
No.
4.1.1.3 OUf decision to appoint the RFP respondent
No.
4.1.1.4 The RFP respondent's ability to enter into a partnership contract with the City of Miami
No.
RFP 291270 Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI 51 4.2 References
4.2.1 Provide two references, including contact details (names individual, postal and email addresses, telephane number), for relevant work your organization has undertaken, alang with a briet one-paragraph summary of the project and description of the specific role your organization played.
[For our answer to this question, please see the trade-secrets copy of our response.]
4.3 Legal
4.3.1 is the RFP respondent/any companies in the RFP respondent's group of companies, and/or any of their directors, key personnel or shareholders owning over 10%, currently, or have any of. them in the past ten years, been subject to:
4.3.1.1 Legal proceedings including bankruptcy or alleged breach of contract
No
4.3.1.2 Criminal charges or convictions listed in Section 1.2.1 of the ICANN Applicant Guidebook
No
4.3.1.3 Investigations by any public or regulatory body including Hfv1 Revenue and Customs, the Information Commissioners Office, or any equivalent public bodies?
No
4.3.2 If so, please provide details.
Not applicable
4.3.3 What is your understanding of the legal implications of servicing any registry operations outside the US.? E.g., data protection, applicabJe law, law enforcement access.
[For our answer to this question, please see the trade-secrets copy of our response.]
4.4 Conflicts of Interest
Please describe any current or potential conflicts of interest your organization may have in relation to this project, including to the proposed dot MIAMI TLD or to the City of Miami.
We are not aware of any current or potential conflicts of interest in relation to this project.
., ! RFP 291270 " 52 Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI RFP291270 Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI 53 5 Glossary
For ease of reading and reference, we have included a glossary of words and acronyms commonly used in the field or specific to this proposal. The glossary entries either define or explain the acronyms. Acronyms are spelled out on first use within the text of the proposal.
A6 Resource record type, variable length data AAAA Resource record type, fixed-length data AIM Alternative Investment Market, a sub-market of Miami Stock Exchange ALAC "At-Large"- ICANN community of individual Internet users API Application Programming Interface AUP Acceptable Use Policy BIND Berkeley Internet Name Domain (Domain Name System) cc country code ccNSO country code Name Supporting Organization ccTLD country code Top Level Domain CEO Chief Executive Officer CFO Chief Financial Officer CoCCA Council of Country Code Administrators COO Chief Operating Officer CPU Central Processing Unit CRS Complaint Resolution Service CTO Chief Technical Officer DNS Domain Name System DNSSEC Domain Name System Security Extension DDoS Distributed Denial of Service DoS Denial of Service DPI Deep Packet Inspection ENUM E.164 NUmber Mapping EPP Extensible Provisioning Protocol Espresso The Minds + Machines registry platform for new TLDs. FTP File Transfer Protocol GAC ICANN's Governmental Advisory Committee GB Gigabyte gTLD Generic Top-Level Domain GUI Graphical User Interface lANA Internet Assigned Numbers Authority ICANN Internet Corporation for Assigned Names and Numbers 10 Identifier
RFP 291270 54 Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI IDN International Domain Name IETF Internet Engineering Task Force IN Internet IP Internet Protocol IPv4 Internet Protocol version 4 IPv6 Internet Protocol version 6 ISlA Hong Kong Telecommunications Users Group ISO International Organization for Standardization ISP Internet Service Provider IT Information Technology ISP Internet Service Provider NOC Network Operations Center NS Nameserver PCAP Packet CAPture PCH Packet Clearing House PONS Power Domain Name System Registrar An organization that sells domain names to the public on behalf of a registry. Registry An organization that manages a TLD. Registry Operator An organization that provides registry services, such as technical back- office services, on behalf of a registry. RFC Request for Comments , RFP Request for Proposal RSPAN Remote Span (Switched Port Analyzer) SLA Service Level Agreement SLD Second Level Domain SMTP Simple Mail Transfer Protocol SNMP Simple Network Management Protocol SOA Start of Authority record SPAN Switched Port Analyzer SQL Structured Query Language SRS Software Requirements Specification TACACS Terminal Access Controller Access Control System TAS TLD Application System TCP Transmission Control Protocol TLD Top-Level Domain TLDH Top-Level Domain Holdings, Ltd. UDP User Datagram Protocol
RFP 291270 Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI 55 UDRP Uniform Domain-Name Dispute-Resolution Policy URS Uniform Rapid Suspension UTC Coordinated Universal Time VP Vice President VPI\J Virtual Private Network WIPO World Intellectual Property Organization
RFP 291270 56 Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI 6 list of Attachments
Attachment Name Attacned to Section: Description
2.8.1- Sample Reports 2.8.1 Sample Reports
2.9.1 Sample Policy 2.9.1 Overall Policy Framework. Includes Framework Registry-Registrar Agreement; model registrant agreement, Acceptable Use Policy; Whois/Privacy Policy; Naming Policy
3.1.6 - Expected Case 3.1.6 Expected Case Pro Formas
3.1.6 - Worse Case 3.1.6 Worse Case Pro Formas
3.1.6 - Optimistic Case 3.1.6 Optimistic Case Pro Formas
RFP 291270 Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI 57 6.1 Attachment 2.8.1- Sample Reports
PLEASE SEE TRADE SECRETS COpy OF RESPONSE TO IRFP
6.2 Attachment 2.9.1- Policy Framework
PLEASE SEE TRADE SECRETS COPY OF RESPONSE TO IRFP
RFP 291270 Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI 6.3 Attachment 3.1.6 - Expected Case Financiais
PLEASE SEE TRADE SECRETS COPY OF RESPONSE TO IRFP
RFP 291270 Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI 59 6.4 Attachment 3.1.6 - Optimistic Case Financials
PLEASE SEE TRADE SECRETS COPY OF RESPONSE TO IRFP
RFP 291270 60 Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI 6.5 Attachment 3.1.6 - Worse Case Financials
PLEASE SEE TRADE SECRETS COpy OF RESPONSE TO IRFP
RFP 291270 Informal Request for Proposals to Establish, Operate, and Administer dot MIAMI