• Reuniões do At-Large de ICANN em Rio de Janeiro, Brasil Domingo, 23 Março 2003
• Reunión del Comite Asesor At-Large del ICANN, en Rio de Janeiro, Brasil, Domingo, 23 de Marzo del 2003

Meeting Notes

Introductions - ALAC members in attendance included Vittorio Bertola, Thomas Roessler, Erick Iriarte Ahon, Sebastián J. Ricciardi, Xue Hong, and Wendy Seltzer. See list below for other attendees.

Briefing/Discussion - WHOIS Accuracy and Bulk Access - WHOIS Task Force Co-Chairs, Marilyn Cade and Tony Harris presented the task force report:

Whois data is an important resource to Internet users including registrants, registrars, businesses, ISPs, intellectual property holders, and governmental law enforcement and consumer protection agencies. The DNSO Names Council (now GNSO Council) established a Whois Task Force in February 2001 in order to study and, as appropriate, formulate recommendations on Whois policies.

On 20 February 2003, the GNSO Council accepted and forwarded to the ICANN Board a Final Report of the GNSO Council's Whois Task Force on Whois Data Accuracy and Bulk Access to Whois Data. (Other issues discussed by the Task Force, such as privacy protections for data subjects, will be presented in separate "issues reports" that will form the basis for further policy-development under the GNSO Council's direction. The issues reports will be published for discussion by the GNSO at the ICANN meetings in Rio de Janeiro.)

The Whois Task Force's Final Report on Accuracy and Bulk Access includes four new consensus-policy recommendations. Two of these recommendations are intended to enhance data accuracy, and two limit the uses that may be made of Whois data obtained under the bulk-access provisions of the registrar accreditation agreements:

1. At least annually, a registrar must present to the Registrant the current Whois information, and remind the registrant that provision of false Whois information can be grounds for cancellation of their domain name registration. Registrants must review their Whois data, and make any corrections.

2. When registrations are deleted on the basis of submission of false contact data or non-response to registrar inquiries, the redemption grace period - once implemented - should be applied. However, the redeemed domain name should be placed in registrar hold status until the registrant has provided updated Whois information to the registrar-of-record.

3. Use of bulk access Whois data for marketing should not be permitted. The Task Force therefore recommends that the obligations contained in the relevant provisions of the [Registrar Accreditation Agreement (RAA)] be modified to eliminate the use of bulk access Whois data for marketing purposes. The obligation currently expressed in section 3.3.6.3 of the RAA could, for instance, be changed to read as follows: "Registrar's access agreement shall require the third party to agree not to use the data to allow, enable, or otherwise support any marketing activities, regardless of the medium used. Such media include but are not limited to e-mail, telephone, facsimile, postal mail, SMS, and wireless alerts." The bulk-access provision contained in 3.3.6.6 of the RAA would then become inapplicable.

4. Section 3.3.6.5 of the Registrar Accreditation Agreement currently describes an optional clause of registrars' bulk access agreements, which disallows further resale or redistribution of bulk Whois data by data users. The use of this clause shall be made mandatory.

Discussion focused on key concerns, including:

• marketing uses of WHOIS data;
• registrars providing bulk access beyond that stipulated in their contracts;
• separating access to and accuracy of WHOIS data;
• impact of recommendations on registrants' (especially individuals') privacy;
• complying with various countries/region's laws;
• treatment of, effect of, proxy services; and
• focusing on display of data rather than accuracy vs. privacy.

Briefing/Discussion - New gTLDs - Louis Touton, ICANN VP/General Counsel, provided an update on ICANN's actions regarding the introduction of new gTLDs (generic top level domains) (including the previous ICANN President's "action plan"):

Seven new gTLDs were chosen by ICANN's Board, which brings the total gTLDs to 14 (FYI, there are 243 ccTLDs - country code domains). gTLDs can be "un-sponsored," such as the ".com" domain for which registry policy is set via ICANN, and "sponsored" gTLDs, such as ".pro" for which there is a defined community represented by organizations that hosts a policy formulation process (ICANN policy is, in part, delegated). "Unrestricted TLDs" are open to registrations by any person or organization for any use and "restricted TLDs") are intended for registrations by particular types of persons or organizations or for particular uses.

At its 23 August 2002 meeting, the ICANN Board of Directors directed ICANN President Stuart Lynn to produce a "plan for action" concerning the implementation of the Report of the New TLD Evaluation Process Planning Task Force. On 18 October 2002, Dr. Lynn posted for comment A Plan for Action Regarding New gTLDs in response to the Board's direction. At its 15 December 2002 meeting, ICANN's Board authorized the President to take all steps necessary to implement those aspects of the NTEPPTF recommendations as specified in the Action Plan, and asked the GNSO to provide a recommendations on whether to structure the evolution of the generic top level namespace and, if so, how to do it.

There are three parts to the "plan for action":

I. A Proposal for the Board to Extend the Proof of Concept in Parallel with Evaluation of the new gTLDs: This proposal provides the Board with the option, should it so wish to do so, of extending the original "Proof of Concept" to solicit up to three more sponsored TLDs, subject to certain conditions, following a suitable, but short, bidding process. Applicants for sponsored TLDs from the previous round would be invited to update their proposals and resubmit them, but new proposals would also be invited.

II. A Plan for Implementing the Key Recommendations of the NTEPPTF Report regarding the Evaluation of New gTLDs: This plan for the Board's consideration proposed how to implement the principal recommendations of the NTEPPTF Report for a Monitoring Program and an Evaluation, while recognizing the limitations of time and funding.

III. A Recommendation that the Board seek DNSO (or its successor) advice on how to evolve the top level generic namespace: This recommends that the Board ask the DNSO (or its successor depending on what evolves in Shanghai) to develop a recommendation on how to evolve the generic namespace, with specific focus on the question as to whether and how to rationalize the space (that is, to develop a taxonomy for top level domains); whether to expand the space strictly according to market demand; or whether to pursue some third alternative; and to develop other principles that should govern the evolution of the namespace. This is an important step towards fulfilling the requirements of Paragraph IIC 8(b) of the recently amended Memorandum of Understanding with the United States Department of Commerce regarding the creation and implementation of selection criteria for new and existing TLD registries, including public explanation of the process, selection criteria, and the rationale for selection decisions.

An RFP (request for proposals) could be issued for sponsored gTLDs.

Discussion focused on key concerns, including:

• What would be the impact on the Net's stability of a few, or many, new gTLDs? The root can support a lot more domains; the IAB recommended that the root zone be operated in a conservative manner and stability flows from the root zone; operational issues of adding more may cause flux (errors) and decrease stability.
• What is the (users') demand for new names? (no demand studies have been done)
• What is the impact of new gTLDs on Registrars? How many names can they "handle"? Would this help or hurt competition? (how successfully are registrars interacting with 7 new gTLDs, especially the smaller ones?)
• Introduction of un-sponsored gTLDs complicates creation and implementation of policy (eg privacy policy more complicated with a lot more un-sponsored gTLDs)

Briefing - ICANN overview; Nominating Committee process - Andrew McLaughlin, ICANN Senior Advisor, provided an overview of ICANN's reformed structure and the Nominating Committee's (NomCom) plans: View the PowerPoint presentation.

At this time NomCom extends an invitation to members of the Internet community to think about the positions to be filled, potential candidates they might recommend, and their own interest in volunteering a Statement of Interest in being considered. By the end of March the Nominating Committee expects to be ready to extend a Formal Call for Recommendations and Statements of Interest for the positions to be filled. When that Formal Call is issued, it will describe the specific information needed by Nominating Committee in these communications, and will describe how the process will work. NomCom plans to complete the development of most of its procedures by the end of March/early April. The Committee expects to the closing date for submissions to be the end of April, and finale selections made by the end of May. The Committee's procedures will be published on the Nominating Committee's homepage.

In the meantime, members of Internet Community are encouraged to review the relevant sections in the Bylaws about the (1) ICANN Mission and Core Values, (2) the roles of Directors, GNSO Council members, and ALAC members; (3) the criteria, qualifications, and eligibility factors for these positions; (4) the Nominating Committee; and (5) the Transition to the New Board so that their Recommendations and Statements of Interest will be well focused and clearly meet the applicable requirements.

Briefing/Discussion - Internationalized domain names (IDN) - Masanobu Katoh, ICANN Director and IDN Committee Chair, presented the paper on Standards for IDN Authorization: View the PowerPoint presentation.

Internet domain names are easy-to-remember identifiers for hosts and services on the Internet. Until now, only a subset of US-ASCII has been usable in domain names. Over the past 2+ years, the Internationalized Domain Name Working Group (IDN-WG) of the Internet Engineering Task Force (IETF) has been working to internationalize the domain name system at the application layer by standardizing a system for the translation of non-ASCII characters into unique ASCII strings that can be resolved by the existing domain name system.

Implementation of IDNA brings significant risks for the domain name system. In particular, serious concerns have been raised about the likelihood of widespread user confusion and new opportunities for cybersquatting. These risks can be greatly reduced by the adoption of sensible registry-level policies, and by the coordination of consistent technical implementations across DNS registries. IDNA will be a major step forward for the domain name system, but only if the DNS registries undertake to implement it in a thoughtful, responsible, and standards-compliant manner. The role of ICANN in this process is, of course, limited - ICANN's agreements with the major gTLD registries give it the responsibility to expressly authorize the registration of IDNA-compliant internationalized domain names, but ICANN's mission does not include micromanaging registry-level implementation.

Accordingly, the IDN Committee proposes an IDN deployment environment of relatively few, vital requirements for implementing registries. This proposed approach would provide a platform of technical compatibility and transparency and promote a cooperative environment in which registries would consult with the relevant user communities to establish registration procedures that are widely adopted, predictable, and broadly acceptable to users.

The first four points below are proposed as mandatory requirements that the registries would be required to agree to as the conditions for ICANN authorization to begin accepting IDNA-compliant domain name registrations. Points 5 and 6 are proposed as strong recommendations to the gTLD registries (and, indeed, to all registries), but would not be made mandatory.

1. Top-level domain registries that implement internationalized domain name capabilities must do so only in strict compliance with all applicable technical standards.

2. In implementing IDNA, top-level domain registries must employ an "inclusion-based" approach for identifying permissible code points from among the full Unicode repertoire, and, at the very least, must not include (a) line symbol-drawing characters, (b) symbols and icons that are neither alphabetic nor ideographic language characters, such as typographical and pictographic dingbats, (c) punctuation characters, and (d) spacing characters.

3. In implementing IDNA, top-level domain registries must (a) associate each registered domain name with one or more languages, (b) employ language-specific registration and administration rules that are documented and publicly available, such as the reservation of all domain names with equivalent character variants in the languages associated with the registered domain name, and, (c) where the registration and administration rules depend on a character variants table, allow registrations in a particular language only when a character variants table for that language is available.

4. Registries must commit to working collaboratively through the IDN Registry Implementation Committee to develop character variants tables and language-specific registration policies, with the objective of achieving consistent approaches to IDN implementation for the benefit of DNS users worldwide.

5. In implementing IDNA, top-level domain registries should, at least initially, limit any given domain label (such as a second-level domain name) to the characters associated with one language only.

6. Top-level domain registries (and registrars) should provide customer service capabilities in all languages for which they offer internationalized domain name registrations.

Subject to feedback and comments from the ICANN community, it is proposed to apply the foregoing standards to the authorization of IDN registrations by registries with agreements with ICANN. The actual procedure would be quick and straightforward: the registry would submit to ICANN an agreed statement of its commitment to abide by the required principles stated in the first four points above. ICANN would, in turn, provide written authorization to the registry to begin accepting IDNA-compliant IDN registrations.

The ongoing IDN implementation tasks of common concern to all registries implementing IDNA - such as the development of character variant and equivalence tables in consultation with local experts and affected registries - must proceed, through the IDN Registry Implementation Committee and the various local and regional bodies that have taken it on. To assure the rapid introduction of IDNs in the major languages' character sets, the development of language-specific rulesets must proceed in parallel, in both formally-constituted and ad hoc groupings of experts and registries (both gTLDs and ccTLDs).

Action item/Discussion - At-Large Infrastructure: Accreditation criteria for At-Large Structures; Approval process for At-Large Structures (ALS); Regional At-Large Organization (RALO) MOU guidelines/template -- definition/composition /structure of RALOsM.

Discussed status of At-Large organizing discussions in various regions: Europe -- ISOC Chapters and federated organizations; Latin America -- ISOC chapters, and ccTLDs work with many local groups, such as IEEE and cyberlaw groups, and could be helpful; Asia - ISOC, NICs, language is barrier; US - ISOC chapters, computer users, consumer groups; and Africa - ISOC chapters.

Noted that publicity and outreach is needed to increase awareness and encourage involvement.

Discussed various approaches for ALS/RALO including an "individual approach" (one person/one vote; short chain of representation, requires little trust - at-large structures as facilitators and certifiers of individual members, has individual members, and is representational) and "organization approach" ("council" model in which organizations' representatives vote, longer chain of representation, requires more trust in approaches, has organizational members, and emphasizes advocacy).