Summary/analysis of public comments received

["Kieren McCarthy" <kieren.mccarthy@xxxxxxxxx>]

Registrar Accreditation Agreement Amendments: Synthesis of Public Comments
Received

 

The ICANN Board of Directors adopted a resolution at the San Juan meeting
that directed staff "to solicit and consider the input of the Internet
community, including the At-Large community and the GNSO constituencies,
regarding proposed changes to the RAA, registrar accreditation process, and
related policies" and to "engage with the Registrars Constituency in order
to arrive at, and post for public comment, a set of proposed amendments or
alternative version to the RAA, that is intended to address to the extent
feasible the concerns raised by the Internet community."


To this end, staff opened a public comment period on the ICANN website to
solicit initial public input (http://www.icann.org/topics/raa/) with the
understanding that such input would be synthesized for discussion with the
Registrar Constituency. This document is intended to provide such a
synthesis. This summary will take into consideration comments received
during the initial period from 30 July through 10 September 2007.


A total of 53 public comments/recommendations were received during the
initial period, with three individuals contributing the majority of comments
(copies of all submissions can be found at
http://forum.icann.org/lists/raa-consultation/). The Intellectual Property
Constituency submitted a redlined version of the RAA to reflect changes it
recommended. A subsequent submission from the At-Large Advisory Committee
(ALAC) was also received and its recommendations are also included in this
summary.


While the recommendations suggest a sincere interest in change, many of the
comments fell outside of the scope of RAA amendments. Because the Board
directed staff to solicit comments on "proposed changes to the RAA,
registrar accreditation process, and related policies", some of the comments
cover qualifications and policy issues that would not be directly addressed
through RAA amendments. Some comments were more general in nature or fell
outside the scope of the ICANN-registrar relationship in other ways. All
comments are listed, but this summary attempts to isolate those items that
will facilitate the discussion on RAA amendments at this time. While staff
wishes to provide for the broad range of input received, some form of
classification was deemed necessary to focus the discussion for the purpose
of amending the RAA. It is possible that some of the suggestions listed
below could fall into more than one category - and views may differ on how
the suggestions should be classified, so attention should be given to the
content of each recommendation, not only its classification.


For those recommendations that may fall outside the scope of RAA amendments,
ICANN wishes to work with interested community members in order to promote
constructive ideas. ICANN will explore different fora for the subsequent
discussion.


All comments have been numbered to provide ease of reference.


 


Consultation on Registrar Accreditation Agreement Amendments: 



Synthesis of Public Comments Received


 

TABLE OF CONTENTS 

A. Proposals <http://www.icann.org/topics/raa/comment-summary.html#a>  taken
into consideration

B. Feasible <http://www.icann.org/topics/raa/comment-summary.html#b>
revisions 

C. Suggestions <http://www.icann.org/topics/raa/comment-summary.html#c>
concerning Accreditation Requirements

D. <http://www.icann.org/topics/raa/comment-summary.html#d>  Recommendations
being addressed in other ICANN fora or covered by an existing policy

E. Suggestions considered
<http://www.icann.org/topics/raa/comment-summary.html#e>  to be under
discussion in the context of a Consensus Policy 

F. Suggestions <http://www.icann.org/topics/raa/comment-summary.html#f>
considered unsuitable as amendments to the RAA 

  _____  

  


A. The following suggestions are in line with the initial amendment
proposals and have been taken into consideration in drafting language that
is being negotiated between the registrars and ICANN.

1.      ICANN should govern terms for sales of registrars to new owners
2.      Require groups of registrars to be responsible for actions of
individual registrars
3.      Require Data Escrow of privacy services data
4.      Enhance requirements of registrars for behavior of resellers
5.      Require operator skills training
6.      Training recommendation for skills testing to help thwart spam
7.      Registrar is responsible for behavior of resellers, including any
penalties
8.      Require resellers to indicate the name of the registrar on its
website
9.      Provide for termination of a registrar for actions of its affiliates
10.     Provide for graduated sanctions
11.     Add a change of control provision that permits ICANN to audit for
compliance following a change of control
12.     Add a control of affiliates provision that extends the agreement to
affiliates
13.     The revised RAA should contain a range of incentives and remedies
short of revocation, such as public admonishment, fines, and temporary
suspension of new registration privileges.
14.     ICANN should require that any registrar that sells through resellers
have binding agreements with their resellers that pass through registrar's
duties to registrants.
15.     The RAA should include the proposed amendment that requires that
when registrars are aware that a registration is performed by a proxy, the
escrowed registrant data must include the information for the actual
registrant, unless the actual registrant opts out. 

 


B. The following suggestions may be feasible to include as revisions to the
RAA and will be included in discussions between the registrars and ICANN.

1.      RAA should allow for arbitration of damages instead of sanctions,
like registry agreements
2.      The leasing of an accreditation should be addressed by the RAA
(without necessarily impacting traditional reseller arrangements)
3.      Expand the data escrow terms to allow use of the data to resolve
disputes between ICANN and the registrar ("The escrow shall further provide
that ICANN may use data held in escrow to protect registrant rights in the
event of Registrar default of the terms of this Agreement and otherwise to
confirm performance with the terms of this agreement. ICANN shall not
disclose any information maintained in escrow to anyone other than the
Registered Name Holder, except in connection with any dispute between ICANN
and the Registrar concerning the Parties' performance of their obligations
under this Agreement. ")
4.      Add a compliance audit provision ("ICANN may at its discretion and
for reasonable cause at any time audit a Registrar or any Affiliate of
Registrar to determine compliance with this Agreement or with
representations made in the Registrar Accreditation Application.")
5.      Add a clause in the RAA so to require registrars to clearly state
the name under which they are accredited by ICANN and the number of their
accreditation contract, at the time of registration and on the invoices /
receipts related to the registration. 


C. Suggestions were submitted concerning Accreditation Requirements, which
should be considered separately from the RAA amendment discussions. These
will be pursued as part of a larger discussion concerning the qualification
requirements to be an ICANN accredited registrar.

1.      Devise new criteria in accreditation process to eliminate applicants
that exist only as paper entities
2.      Use economic studies to determine if changes in accreditation
requirements could be instituted to remove barriers to entry by applicants
in the developing world. 


D. This group of recommendations includes issues that are currently being
addressed in other ICANN fora or are covered by an existing policy,
proposal, or items that will be considered as enhancements to existing
practices and procedures, but that do not require RAA amendments.

1.      Registrars should provide challenge mechanism to correct Whois
identity theft (Legal and Policy options already exist)
2.      Curtail domain tasting - two comments (Under consideration by the
GNSO)
3.      Transfer of domain names between registrars should happen
"seamlessly" within 24 hours (Inter-Registrar Transfer Policy exists to
govern transfers; Transfer Policy is under review by GNSO)
4.      Only actual registrant information should be displayed in Whois -
not privacy services (Under consideration in the present Whois policy
discussion)
5.      Registrars and registries should be prohibited from selling Whois
check (name availability lookup) data (SSAC is conducting a review of this
possible practice)
6.      Registrars should be sanctioned if they don't release Auth-Info
codes in a timely manner; registrants should be permitted to acquire
Auth-Info codes directly from registry; registries may need to be made
"thick" (Policy exists covering the provision of Auth-Info codes)
7.      Mandate an opt-out provision to let registrants keep their
information out of bulk access data (Under consideration in the present
Whois policy discussion; also dealt with by Registrar Constituency RAA
amendment proposal)
8.      Impose a means for contacting underlying registrant when
privacy/proxy service is used (Under consideration in the present Whois
policy discussion)
9.      Adopt a registrar Code of Conduct (Provision already exists in RAA;
requires consensus of registrars to adopt a Code of Conduct)
10.     ICANN should post registrar violations by name (ICANN's Compliance
escalation procedures contain provisions for publication of violations under
certain circumstance)
11.     Require registrars to include a link for reporting bad Whois in the
Whois lookup record that links to ICANN's WDPRS
12.     Convene an accreditation workshop (Such a workshop has been
scheduled for the ICANN meeting in LA)
13.     Add a provision that spells out terms under which a registrar can
substitute contact details in the Whois record for the actual Registered
Name Holder and that facilitates timely resolution of problems involving
those names (Under consideration in the present Whois policy discussion)
14.     Require registrar to provide contact information for licensed domain
names (Under consideration in the present Whois policy discussion)
15.     Require registrar to provide "accurate" and "valid" contact details
that are regularly checked by the registrar and requires registrar to
respond to third party inquiries concerning names under management within 24
hours (Under consideration in the present Whois policy discussion)
16.     ICANN should define internal procedures to monitor registrar
compliance, accept public reports of problems and non-compliance, and engage
in corrective actions in a timely fashion. (ICANN's Compliance unit has such
procedures)
17.     ICANN should establish an online method specifically to accept
complaints about registrar behavior; while ICANN cannot generally solve
individual problems, consumers can still receive pointers to useful
information in various languages, and to appropriate consumer protection
agencies and organizations. This mechanism would allow ICANN to extract
aggregated information to recognize developing problems with
registrars.(Online complaint filing exists, while the Translation Policy is
under development to address a variety of translation needs)
18.     ICANN should continue to conduct regular assessments of the
compliance of each registrar, either directly or through third parties,
using a standardized checklist that verifies the compulsory behaviors (e.g.
compliance with applicable ICANN policies), the average levels of service
(e.g. technical performance, average rate and speed of response to customer
inquiries), and a set of performance indicators that could warn about
possible problems (e.g. degradation over time in new registration and
transfer-away rates). Compliance should be verified at least once a year.
(ICANN's Compliance unit has an annual audit schedule for registrars)
19.     Using automated electronic means (e.g. search engines), ICANN should
identify and combat abuses of the "ICANN accredited" logo by unaccredited
parties. (ICANN regularly monitors uses and aggressively challenges abuses
of its logos)
20.     Develop a clear and uniform document describing the roles,
requirements and use of the different contacts, that could be used as a
reference document by registrants and by third parties registering domain
names on their behalf, also in case of controversies between them. (Under
consideration in the present Whois policy discussion)
21.     We ask that ICANN provides official translations of the transfer
forms and rules into major languages; the registrant should be able to
perform the entire procedure in his/her native language, if it is one of the
supported ones. (ICANN's Translation Policy is under development to address
a variety of translation needs)
22.     ICANN should establish procedures to follow when a registrar has
failed, to select one or more other registrars to which to transfer the
registrants. (Procedures for handling of registered names managed by failed
registrars are under discussion)
23.     ICANN should establish procedures to verify that registrars are
properly escrowing data, by spot checks and other means. (ICANN's registrar
data escrow program has such provisions)


E. ICANN is structured so that major policy decisions with broad impact are
arrived at through a bottom-up consensus process. The following suggestions
are considered by staff either to be under discussion in the context of a
Consensus Policy already or, otherwise because of their nature, could/should
be handled through the Consensus Policy process. Adopted Consensus Policies
are enforced through the RAA.

1.      ICANN should establish or provide a dispute resolution mechanism for
unauthorized changes of registrant
2.      ICANN should require registrars to verify registrant identity
3.      Registrars should be prohibited from registering and otherwise
acquiring domain names and should be divested of domain name registrations
4.      ICANN should create a registrar shared database of "invalid" domain
names
5.      Require adherence to Consensus Policy - eliminate post expiration
loopholes (Staff note: Consensus Policy compliance enforcement already
exists, further limitations to existing policy would require the adoption of
additional Consensus Policies)
6.      ICANN should assure that a centralized Whois be established that is
searchable to benefit UDRP complainants
7.      ICANN should reconvene the Technical Steering Committee to introduce
competition into the RGP
8.      Require verification by mail of a registrant's address prior to
activating domain name
9.      Establish registrar action deadlines for dealing with registrant
non-compliance
10.     Enable registrars to do mass deletions of names registered by proven
serial spammers and block attempts at future registrations
11.     Contact data should be verified at the time of collection.
12.     While the obligations of registrars for what regards transfers are
implicit in their obligations to abide by ICANN consensus policies, we think
that, given the extreme importance of this policy, it would be useful to add
a clear reminder in the RAA, under the form of a clause saying something
like "The registrar recognizes the right of the registrants to transfer
their domain names to other registrars, according to the policies
established by ICANN, and commits to make the process of transferring domain
names as simple and quick as possible, and not to unreasonably stifle this
opportunity in any way."
13.     We ask that the GNSO Transfer Policy include specific requirements
to enable transfer of domain names. Registrants should be able to process a
transfer entirely through the services of the gaining registrar and/or the
registry, without the need for action by the losing one, including obtaining
Auth-Info codes and the like when required.
14.     We ask that the GNSO Transfer Policy forbid losing registrars to
require an extra fee or paperwork to transfer their domain names. Since the
entire transfer process can be automated, its operational cost is so low to
be covered by the registration fee, and there is no cost justification for
extra fees.


F. The remaining suggestions were considered by staff to be unsuitable as
amendments to the RAA either because they cannot be feasibly implemented as
RAA provisions, because the issue is best addressed through the freedom and
choice available to registrants as they select a registrar, or because they
are beyond ICANN's mission and scope. To the extent feasible registrars or
other parties may be in a position to implement some of these
recommendations.

1.      ICANN should limit disclaimers in registration agreements and
require registrars to accept some legal liability
2.      ICANN should require standardized Acceptable Use Policy in
registration agreements to address criminal fraud
3.      Registrars should be required to offer a 30 day auto-renew grace
period after expiration of a registration
4.      ICANN should take steps to ensure impartial, equal, and fair access
by preventing special access to domain speculators
5.      Revoke domain names that are sold for more than "face value"
6.      Restrict the number of domain names that can be registered by a
single entity in a specified period of time
7.      ICANN should disallow domain name parking
8.      Expired domain names should be available to original registrant for
an extended period of time
9.      Unauthorized registrar switching ("domain name slamming") should be
prevented
10.     Actual registrant should control name, not a third party
registration service
11.     ICANN should publicly display all registrar officers and directors,
particularly when a registrar's accreditation is terminated
12.     ICANN should include penalties from registrars to registrants for
poor service as an enforcement tool
13.     ICANN should create penalties for registrars to discourage
typosquatting
14.     Create common RAA and Whois requirements across all TLDs (including
ccTLDs)
15.     Registrars should be required to offer DNSSEC
16.     ICANN should require registries to notify ICANN when accounts become
under-funded; ICANN must issue Public Alerts when this occurs
17.     Terms of Service Agreements should not be used to circumvent
Consensus Policies
18.     By Code of Conduct or RAA, registrars should heed security-driven
recommendations
19.     Add the right to inspect registrars in order to police use of the
ICANN name and reputation
20.     ICANN should consider transferring the burden of enforcing the RAA
from itself to domain name registrants by making domain name registrants
third-party beneficiaries of the RAA.
21.     Add a clause in the RAA to require registrars to show a standardized
description of registrant rights, to be provided by ICANN in different
languages, as an appendix to the contract at the time of registration, and
also to make it available in the registrant's domain management interface
whenever available. Such obligation should also be passed onto resellers.
22.     We ask ICANN staff to prepare a summary of the current practices,
fees and burdens imposed on registrants by a significant sample of
registrars. (The ALAC is ready to ask for an Issues Report if necessary).
23.     ICANN should appoint a separate entity, targeted with the task of
conducting compliance assessments similar to those delineated in Compliance
above. A suitably independent entity could do the assessments both for the
purpose of ICANN's compliance verification activity, and for the purpose of
releasing ratings. Consumers Union, an ALS in the United States with
extensive experience
24.     The delegated entity should continue to conduct assessments at least
once a year, and should produce a graded rating published on ICANN's website
and on a specific page aimed at final consumers, and disseminated over the
Internet through outreach and information campaigns.
25.     Registrars obtaining top grade evaluations should be allowed to
display a specific mark on their website.
26.     Registrars obtaining a very low grade should be immediately subject
to specific corrective measures by ICANN, and, if appropriate, to sanctions
according to the compliance provisions of the RAA.
27.     ICANN should have an inexpensive program to accredit resellers.
28.     ICANN should consider including resellers in the compliance and
rating evaluations described above.
29.     ICANN should define criteria to determine when a registrar has
failed, such as failure to process transfers and registrations in a timely
fashion. Voluntary closure of a registrar should be treated as failure
unless the closing registrar has taken action to transfer all of its
registrants to other registrars.
30.     ICANN should use the results from the compliance and rating
assessments, as well as any other available information, to monitor which
registrars appear subject to possible failure in the near future. 

 

 

----------------------

Kieren McCarthy

----------------------

General manager of public participation, ICANN

http://www.icann.org <http://www.icann.org/>