|
IANA Report on the Delegation of the .MOBI Top-Level Domain(Date: October 2005) |
The Internet Assigned Numbers Authority (the IANA), as part of the administrative functions associated with management of the domain-name system root, is responsible for receiving requests for delegation and redelegation of top-level domains, investigating the circumstances pertinent to those requests, and reporting on the requests. This report provides the findings and conclusions of the IANA on the delegation of the .MOBI Top Level Domain (TLD).
There are several types of TLDs within the DNS, including TLDs with three or more characters referred to as “generic” TLDs, or “gTLDs.” They can be subdivided into two types, “sponsored” TLDs (sTLDs) and “unsponsored” TLDs, as described in more detail below.
Generally speaking, an unsponsored TLD operates under policies established by the global Internet community directly through the ICANN process, while a sponsored TLD is a specialized TLD that has a sponsor representing the narrower community that is most affected by the TLD. The sponsor thus carries out delegated policy-formulation responsibilities over many matters concerning the TLD.
A Sponsor is an organization to which is delegated some defined ongoing policy- formulation authority regarding the manner in which a particular sponsored TLD is operated. The sponsored TLD has a Charter, which defines the purpose for which the sponsored TLD has been created and will be operated. The Sponsor is responsible for developing policies on the delegated topics so that the TLD is operated for the benefit of a defined group of stakeholders, known as the Sponsored TLD Community, that are most directly interested in the operation of the TLD. The Sponsor is also responsible for selecting the registry operator and, to varying degrees, establishing the roles played by registrars and their relationship with the registry operator. The Sponsor must exercise its delegated authority according to fairness standards and in a manner that is representative of the Sponsored TLD Community.
The extent to which policy-formulation responsibilities are appropriately delegated to a Sponsor depends upon the characteristics of the organization that may make such delegation appropriate. These characteristics may include the mechanisms the organization uses to formulate policies, its mission, its guarantees of independence from the registry operator and registrars, which individuals or entities will be permitted to participate in the Sponsor's policy-development efforts and in what way, and the Sponsor's degree and type of accountability to the Sponsored TLD Community.
On 26 June 2003, at the ICANN Board meeting in Montreal, the Board directed ICANN staff to invite public comment on a draft request for proposals for sTLDs posted on 24 June 2003, and in particular on the question whether the RFP should be limited to applicants that had proposed sponsored TLDs in November 2000. The public comments are available at ICANN’s website at http://forum.icann.org/mtg-cmts/stld-rfp-comments/general/index.html.
In parallel with the public comments, the ICANN Board discussed at length the topic of how, and within what timeframe, ICANN should proceed with the creation of new gTLDs, including sTLDs. On 29 October 2003, the GNSO called upon the Board to go forward with the process for an interim round of sTLDs.
Following various community discussions, including input by experts and interested parties through the GNSO, and from users both directly and through the At-Large Advisory Committee (ALAC), on 31 October 2003, at its meeting in Carthage, Tunisia, the ICANN Board directed the ICANN President to finalize and post no later than 15 December 2003 an open Request for Proposals, not restricted to prior applicants, for a limited number of new sTLDs. The final RFP was to be based on these conclusions and the comments received concerning the posted draft.
In response to this direction, on 15 December 2003, ICANN announced and released the request for proposals (RFP) for sTLDs. The RFP was divided into six parts, see http://www.icann.org/tlds/new-stld-rfp/new-stld-application-parta-15dec03.htm. The first part provided explanatory notes on the application and evaluation process, as well as on the type of information requested by ICANN. The remaining parts constituted the application itself.
The RFP’s explanatory notes described the selection criteria, which were in brief:
ICANN received 10 applications for new sTLDs before close of the application period on 16 March 2004. Applications were received for the following 9 sTLD strings: ASIA, .CAT, .JOBS, MAIL, .MOBI, POST, TEL, TRAVEL and XXX. Two different applicants submitted applications for TEL. The public parts of the ten applications were posted on the ICANN website at http://www.icann.org/tlds/stld-apps-19mar04/stld-public-comments.htm for public comment. The public comments received were posted at the same location.
An independent panel of experts with substantial knowledge of relevant technical, business/financial and policy areas was established to review and evaluate the applications. The internationally diverse panel was separated into three teams, with each one focused on technical, business/financial or policy areas. The teams began their work in May 2004 and completed their reports in July 2004. The independent review procedures ensured that all communications involving the evaluations were made through the Project Manager and as such, the review was blind between the teams and ICANN staff and between the teams and the applicants. The identity of the experts serving on the evaluation teams is confidential until conclusion of the evaluation process.
Each of the three review teams met six to eight times by teleconference. Each team posed a series of questions to applicants, seeking clarification of points relevant to evaluation of the applications against the RFP criteria. Each team provided a separate report, assessing the information in the applications against the criteria – technical, business/financial and sponsorship/community value – that they were charged with evaluating.
In the case where an applicant passed all three sets of criteria and there were no other issues associated with the application, it proceeded to technical and commercial negotiations designed to establish a new sTLD.
In cases where an evaluation team indicated that a set of criteria was not met, or other issues had to be addressed, ICANN gave each applicant an opportunity to submit clarifying or additional documentation.
The registry operator and Sponsoring Organization (SO) for the .MOBI sTLD is DotMobi, Ltd, an Irish limited liability company (“DotMobi”). The .MOBI application for the TLD was submitted by Nokia Corporation, Vodafone Group Services Limited and Microsoft. The registry operator selected Afilias Limited to provide back-end registry services.
Each of the three evaluation teams described above reviewed the .MOBI application. Their recommendations were transmitted to ICANN on 12 July 2004.
The technical evaluation team found that the application did not meet all relevant criteria. It noted concerns about (1) “the disruptive behavior of servers and clients that just assume the use of .mobi TLD for small device content, rather than use content delivery protocol negotiation mechanisms”; (2) “namespace fragmentation if mobile devices use search strings that try <domain-name>.mobi before <domain-name>” because “such a practice would force content providers to register in .mobi to defend their interests in other TLDs”; and (3) users getting “locked-into services that become available only in .mobi by connection providers.” It also noted concern about “registrations . . . being open to abuse, as there is no explicit verification mechanism whether, for example, websites actually follow some specific requirement for either small devices or devices connected over slow bandwidth.”
The business/financial evaluation team reviewed the .MOBI applicant’s business and financial plans and concluded that the relevant selection criteria had been met.
The sponsorship/community value evaluation team found that the application did not meet all relevant criteria. The team indicated that it “is not clear that it is possible, especially over time, to establish the membership of this community. It also did not “believe that the application articulated the most appropriate policy formulation environment for a highly commercial and exclusive organisation,” noting “concerns about bias on behalf of the financial backers of the JV [Joint Venture partners].” The team was “not persuaded that the joint venture partners could implement a cohesive policy formulation environment that aligned with ICANN policy setting priorities” because the “perception of bias would discourage the broader community from participating and cast doubt on the fairness of the resulting decisions.” In addition, the team indicated it was “not clear whether the Policy Advisory Group (PAG) and the Membership Advisory Group (MAG) were self-selecting on the basis of financial capability which would be an excluding element in their organisation. It was thought that whilst the policymaking process takes input from a variety of advisory organizations, decisions are made by the board of directors, chosen from amongst those that invest in the venture. This may not be the best scenario for the board to take the larger community input into account.”
On 3 September 2004, .MOBI responded to the report of the technical evaluation. In response to that team’s concerns, .MOBI suggested that they were not relevant to the question of whether the four technical criteria of the RFP had been satisfied, which it believed had occurred. .MOBI indicated that (1) it would “utilize existing Internet standards, such as content negotiation, and will promote their use within the .mobi style guide and other publications”; (2) the diversity of participants in the “policy making structure will discourage unilateral and non-user friendly imposition of “mobi-only” Internet browsing on mobile devices or policies posing restrictions for .mobi users to access the Internet”; and (3) “its management and agenda will not be “driven by any mobile manufacturer, operator or content providers with an intent to lock-in users to the .mobi domain.” .MOBI also suggested that concerns about defensive registrations were not grounds for disapproval.
On 13 September 2004, .MOBI responded to the report of the sponsorship/community value evaluation team. In response to that team’s concerns, .MOBI explained that (1) “policy requirements, which cannot reasonably be met in existing TLDs at the second level or in new generic TLDs, can be enforced by way of a charter with ICANN for the benefit of consumers,” notwithstanding the size of the anticipated sponsored community, or changes in the community; (2) there is a need for a “clearly recognizable designation for enhanced services [for mobile devices] that can be implemented today and easily understood” by customers, particularly in the developing world; (3) the policy mechanism “permits total flexibility”; and (4) although the policy boards are advisory, the .MOBI Board will be “accountable to the MAG and PAB, to ICANN itself, and to competition authorities around the world.”
On 4 and 15 October 2004, ICANN, the technical team and .MOBI held teleconferences to discuss the concerns raised about validation, content negotiation and mobile device restrictions. The applicant (1) agreed to specify in writing the validation and enforcement procedures that it would use; (2) explained why it believed protocol negotiation protocols now in effect to be insufficient; and (3) stated that .MOBI TLDs would be available to any device, and that anyone on a mobile device can get to any TLD (i.e., it would be up to the user, and not the device, i.e., there would be no “lock-in” or exclusion). It agreed, in particular, to provide “a detailed technical description of the validation and enforcement process it will use, including means of communication between parties, process for bringing registrants into compliance with the style guide, rights of registrants, and other specific steps, as well as confirm whether the processes are supported by the current business plan.”
On 21, 28 and 29 October 2004, the applicant provided follow-up information requested by the technical team, including answers to specific questions and a description of the “.mobi Style Verification Process.”
On 26 November 2004, the technical team indicated its view that .MOBI “has not been able to convince us of the technical merit of its application beyond the criteria specified in the RFP” because of “significant concerns about deployment of a TLD for content negotiation reasons”. The team found there was an absence of technical arguments to support .MOBI’s belief that “currently mobile devices are not well served by standard content sites,” and that “the best way to address this issue is to create a new TLD.” The team felt it was “ unclear what happens if the content negotiation in the protocol is violating the style guide regarding mobile content and the domain name used is in the .MOBI TLD, and that in any case it would not be possible to guarantee that “the style guide would not override the protocol negotiations.” The technical team noted that .MOBI did amend its application to satisfy concerns about validation with two additions: (1) “a registrant must sign an agreement to comply with the .MOBI style guide . . . and understand that [it] will be revoked” for non-adherence; and (2) there would be a “compliance checking process” put in place, including how a registrant will be contacted when not in compliance.
On 10 December 2004, .MOBI responded to the technical team’s Comments. The response emphasized that the technical team had concluded that the application met the “technical requirements of the RFP,” and suggested that .MOBI did not have to prove that the proposed TLD was required for technical reasons. .MOBI indicated that concerns about fragmentation of the Internet were unfounded, and that the style guides and content negotiation are “complementary rather than in conflict.”
On 13 December 2004, after review of the above-mentioned information and materials, ICANN’s Board of Directors authorized the entry of commercial and technical negotiations with the .MOBI applicant (http://www.icann.org/minutes/resolutions-13dec04.htm). The Board requested that, in the process of negotiations, “special consideration be taken as to confirm the sTLD applicant’s proposed community of content providers for mobile phones users, and confirmation that the sTLD applicant’s approach will not conflict with the current telephone numbering systems.”
On 3 June 2005, ICANN announced the completion of those negotiations and posted the proposed .MOBI Sponsored TLD Registry Agreement prior to Board consideration (http://www.icann.org/announcements/announcement-03jun05.htm).
The agreement was then submitted to the ICANN Board for review at a Special Meeting of the Board on 28 June 2005 (http://icann.org/minutes/resolutions-28jun05.htm). The Board noted that “the applicant has provided satisfactory details as to the proposed community of content providers for mobile phones users, and confirmation that the applicant's approach will not conflict with the current telephone numbering systems.” It found that “delegation of a .MOBI sponsored top-level domain to DotMobi, Ltd. would be beneficial for ICANN and the Internet community.” The Board approved the agreement and directed the President of ICANN to implement its decision.
The .MOBI agreement establishes technical operational requirements for the new sTLD. It delegates to the registry operator of .MOBI, DotMobi, Ltd., the authority to develop policies governing such topics as eligibility for registration within the .MOBI TLD, consistent with the terms of the agreement. It also requires the registry to conduct its policy-development activities in a manner that allows members of the .MOBI community to discuss and participate in the development of these policies. The sponsored TLD model promotes stable technical operation by requiring adherence to the standard specifications on such topics as name service, data escrow, and use of valid host names, while providing a substantial degree of autonomy for development of community-specific policies.
On 11 July 2005, ICANN and DotMobi signed the Registry Agreement.
On 9 September 2005, DotMobi submitted a delegation template to IANA, which lists mTLD, Limited as the requested Sponsoring Organization. The designated Administrative Contact and Technical Contact roles will be shared by mTLD Limited and Afilias, Limited.
This report is being provided under the contract for performance of the IANA function (http://www.icann.org/general/iana-contract-17mar03.htm) between the United States Government and ICANN. Under that contract, ICANN performs the IANA function, which includes receiving delegation and delegation requests concerning TLDs (http://www.icann.org/general/iana-contract-17mar03.htm#C.2.1.1.2), investigating the circumstances pertinent to those requests, making its recommendations, and reporting actions undertaken in connection with processing such requests.
In acting on delegation requests, the IANA currently follows the practices summarized in “Internet Domain Name System Structure and Delegation.” (ICP-1, http://www.icann.org/icp/icp-1.htm) ICP-1 represents an update of the portions of RFC 1591 (http://www.rfc-editor.org/rfc/rfc1591.txt) dealing with TLDs, which was issued in March 1994, and reflects subsequent documents and evolution of the policies followed by the IANA through May 1999.
As discussed above, the application for .MOBI was approved by ICANN after an open request for proposals involving several opportunities for public review and comment, evaluation by an independent panel of experts, and review by the ICANN Board. As described above, three teams of experts reviewed the .MOBI application against the specified technical, business/financial and sponsorship/community criteria, respectively, laid out in the RFP. These reports are included in Appendices B, E and G. The teams’ recommendations were then reviewed by the ICANN Board. The Board decided to accept the recommendations of the business/financial team that the RFP criteria were met. After review of the recommendations of the technical team and the sponsorship/community value team, and the response materials submitted by the applicant, the Board decided that the applicant should proceed to technical and commercial negotiations designed to lead to approval of a new sTLD. Subsequent to successful conclusion of these negotiations, the Board approved a Sponsored TLD Registry Agreement for .MOBI, see http://icann.org/minutes/resolutions-28jun05.htm.
ICANN has now completed contractual arrangements with DotMobi for the introduction of a new sponsored .MOBI TLD.
Based on the foregoing evaluation, ICANN concludes that the proposed delegation will promote service to the Internet community and will help assure the continued Internet interoperability through the global technical coordination that ICANN was created to provide. ICANN concludes that the .MOBI TLD should be established and delegated to DotMobi.