ICANN|ARCHIVES

Internet Corporation for Assigned Names and Numbers

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:

• Appendix F to the Registry Agreement is the Registry-Registrar Agreement under which GNR provides registry services to all accredited registrars on an equivalent basis. It would be amended to incorporate the new product offering to registrars.
• Appendix G describes the maximum fee that a registry operator agrees it will charge for the sole-source services it provides to registrars. Appendix G would be changed to include the maximum price for second-level registrations.
• The "Registration Restrictions" set forth in Appendix L would be modified so that the naming convention would incorporate the second-level product (for example <FirstNameLastName.name> or <LastNameFirstName.name>), while the current format would continue to apply to third level registrations which is for example <firstname.lastname.name> (note the dot between first and last name).
  
  The definition of a "Personal Name" in Appendix L would not change; it would continue to be defined as a person's legal name, or a name by which the person is commonly known. The eligibility requirements for registrations of personal names as listed in part 1 of Appendix L would be extended to cover the second level registrations.
  
  Appendix L would also reflect the prohibition of second-level registrations as necessary to secure the third-level namespace. The proposal from GNR contains three strategies for reserving common and popular first and last names. The names resulting from these analyses would be referenced in Appendix L.

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:

• The first strategy ("Government Input") calls on governments to provide GNR with input on common country-specific personal names, as well as information on distribution patterns within those countries.
• Under the second strategy (" Registry Common Name Reservations") GNR proposes to reserve a large amount of popular first and last names that together will result in an estimated 96% of the world population's names being reserved on the second level. (Note: only precise first and/or last names will be reserved, hence it will still be possible for private individuals to register, for example, <InitialLastName.name>.)
• The third strategy ("Post-fix Reservations") calls for the prohibiting the registration at the second level of named ending in post-fixes such as "-family" and equivalent post-fixes in other languages. Thus, the second-level name <morgan-family.name> and <esposito-famiglia.name> could not be registered, but would be reserved to preserve the ability to register at the third level.

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.