ICANN Montréal Meeting Topic: GNR Proposal for .name SLD Service
Posted: 19 June 2003
One topic scheduled for discussion at the ICANN Public Forum to be held in Montréal, Canada on Wednesday, 25 June 2003 is a proposal by The Global Name Registry (GNR – the ICANN-designated operator of the .name registry) to begin offering domain registration services at the second level in addition to the current offering of .name registrations at the third-level. For illustration, GNR proposes to offer individuals (through registrars) the ability to register domain names in the format <firstnamelastname.name>, instead of <firstname.lastname.name>, as is available now.
GNR's proposed new service is scheduled only for discussion in Montréal; any action by ICANN in response to the proposal would not take place until a subsequent ICANN Board meeting.
Legal Considerations and Summary of the .name SLD Proposal
After some preliminary discussions with ICANN staff, GNR submitted to ICANN on 17 June 2003 a formal request to amend its Registry Agreement to allow GNR to offer second-level domain registrations. The proposal seeks to allow the alternative option of registering second-level names, while at the same time securing (with only minor compromise) the size and utility of the third-level space by three parallel ways of reserving common first and last names on the second level.
The proposal would require modifications to Appendices F, G, and L to the .name registry agreement, as specified below:
Reservation of Third-Level Namespace
The original structure of .name allowed individuals to make registrations corresponding to their own personal name (firstname.lastname.name or lastname.firstname.name) in the third level only. This structure allows several individuals with the same last name to each get their own identity on the web, instead of allowing one individual to have the right to all third-level domains under a particular lastname.name registration. In its second-level registration proposal, GNR includes three mechanisms for preserving the utility of the three-level structure of the .name top-level domain as originally proposed in October 2000 and selected by the ICANN Board in November 2000.
The three mechanisms for preserving this structure, while allowing the additional option of offering second-level domain registrations and hence ensuring as little interference as possible between the two types of products, are as follows:
Recommendation for Process
Requests by registry operators to offer new registry services ordinarily involve revision of the registry agreement between ICANN and the registry operator. They can, but do not necessarily, involve changes in policies. In considering past registry requests to implement new services, ICANN has followed a two-part analysis.
Under this analysis, ICANN first applies a preliminary "quick-look" evaluation to determine whether it is plausible that the legitimate interests of others could be harmed by the proposed amendment. As the Board noted in resolution 02.100, "ICANN should act in a way that promotes consumer choice and innovative services while ensuring that registry operations are conducted in a manner that does not harm the legitimate interests of consumers or others." If no legitimate interest appears in danger of being harmed, then the request for modification of the agreement is considered under a streamlined procedure. If, however, there are specific reasons to conclude that the legitimate interests of others are likely to be harmed, this suggests that the contractual revision may involve a change in policy to be considered through the formal policy-development process.
As stated in Appendix A of ICANN's Bylaws, other factors that provide guidance on whether an issue is appropriate for a formal policy-development process include whether the issue:
a. is broadly applicable to multiple situations or organizations;
b. is likely to have lasting value or applicability, albeit with the need for occasional updates;
c. will establish a guide or framework for future decision-making; or
d. implicates or affects an existing ICANN policy.
As indicated above, ICANN's Board will not be asked to take action on GNR's proposal until a subsequent meeting (after Montréal). Based on the analysis above, it would be helpful to the Board, in considering GNR's request, for community discussion of the proposal to focus on (1) whether it is plausible that the legitimate interests of others could be harmed by the proposed new service and (2) how the four additional factors noted above should be analyzed to determine whether the GNR proposal is appropriately considered without the invocation of a formal policy-development process.