- 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.
In October 2002, a significant milestone toward internationalization of
the DNS was achieved when the Internet Engineering Steering Group
approved for publication the three documents that together define
Internationalizing Domain Names in Applications (IDNA), a
standards-track protocol. These three documents were published as
RFCs 3490,
3491, and 3492
in March 2003. Implementation of the IDNA specification by DNS
registries will allow users to use domain names with non-ASCII
characters.
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).