Skip to main content
Resources

Background Papers | Briefing Regarding GNR Proposal for .name SLD Service

To the Board:

On the agenda for the 8 August 2003 Board meeting is the 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>, in addition to <firstname.lastname.name>, as is available now.

Process and Background

After some preliminary discussions with ICANN staff, GNR submitted to ICANN on 17 June 2003 a formal proposal to allow GNR to offer second-level domain registrations through its existing agreement with ICANN for operation of the .name tld. 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.

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.

The .name proposal was presented to the Board at the Public Forum meeting in Montreal. To explore whether third parties might be harmed by implementation of the proposal, the community was invited to provide comments on the proposal at the open microphone at the Public Forum in Montreal, and via e-mail to name-second-level-comments@icann.org. The comments received are posted at <http://forum.icann.org/mtg-cmts/name-second-level-comments/general/index.html>.

Only two people submitted comments. Marcus Faure of CORE Council of Registrars inquired about whether the value of previous third-level registrations would be diminished by proposed availability of services at the second level. His question was answered by GNR's Geir Rasmussen, noting that the introduction of a second level domain product will not affect current users or products, and that the second level e-mail forwarding service will continue to be a useful product even after the introduction of a second level domain offering. The other comment was based on a misunderstanding of both the current proposal and .name eligibility requirements.

As a supplement to its proposal, GNR has submitted a paper to the board explaining the background and rationale for the request.

Based on the above, and the analysis of the .name proposal set forth at <http://www.icann.org/montreal/name-second-level-proposal.htm>, it appears that it is not plausibl that the legitimate interests of others could be harmed by the .name proposal, and therefore the ICANN staff believes that the board may authorize revision of the .name registry agreement without referring the proposal to the formal policy-development process.

Implementation Notes

The approval of the proposal will require modifications to various appendices to the .name Registry Agreement. Below is a summary and overview of the modifications needed to Appendix F, G, L and K - which constitute the main changes necessary for the implementation of the proposal.

  • 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 (proposed to be a maximum of US$6.00) 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 Eligibility Requirements currently permit an individual to (1) register his or her own personal name, (2) register the personal name of a fictional character in which the registrant has rights, and (3) register a domain name containing numeric characters to the beginning or the end of their personal name so as to differentiate it from other personal names. The definition of a "Personal Name" in Appendix L would not change and 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 K would 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, as described in Appendix K. The names resulting from these analyses would be referenced at <http://www.nic.name>.

Respectfully submitted,
Tina Dam
Chief gTLD Registry Liaison

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."