[council] Rationale for the approval of the registrar accreditation agreement (RAA)

[Bruce Tonkin <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx>]

Hello All,

Below is the rationale for the approval of the registrar accreditation 
agreement.

Regards,
Bruce Tonkin

From:  http://www.icann.org/en/groups/board/documents/resolutions-27jun13-en.htm

Rationale for Resolutions 2013.06.27.07 ?C 2013.06.27.09

Why is the Board addressing this issue now?

The long-standing negotiations on the 2013 RAA have come to a successful close, 
and a proposed 2013 RAA was presented to the Board.  It is important for the 
2013 RAA to be approved at this time, as the Board has accepted the GAC Advice 
in the Beijing Communiqué that the "the 2013 Registrar Accreditation Agreement 
should be finalized before any new gTLD contracts are approved."   Approving 
the 2013 RAA now allows the Board to meet this advice.    In addition, ICANN 
has made multiple representations to the community that the 2013 RAA will be in 
place prior to the delegation of new gTLDs.   Approving the 2013 RAA now also 
gives ICANN and the registrars certainty of the new terms that will be 
applicable, and allows both ICANN and the registrars to move forward with 
implementation work to meet the heightened obligations.   Finally, the ICANN 
community has been long awaiting the new RAA after following the negotiations 
since the end of 2011.


What is the proposal being considered?

The 2013 RAA includes provisions addressed to protect registrants through a 
further updated contractual framework.   The 2013 RAA reflects hard-fought 
concessions on many of key issues raised throughout the negotiations, as well 
as issues raised within public comment.   The 2013 RAA, represents a 
significant improvement over the current 2009 version, and significantly raises 
performance requirements for every ICANN accredited registrar, thereby bringing 
dramatic improvements to the domain name ecosystem.


The highlights of this proposed 2013 RAA include:

■  The 12 Law Enforcement Recommendations that served as the impetus for these 
negotiations are all addressed in this proposed draft.   The attached Law 
Enforcement Summary Chart identifies the section or specification of the 2013 
RAA that addressed each recommendation.   Some of the highlights include the 
creation of an abuse point of contact at each registrar, Whois verification and 
validation requirements at the registrant and the account holder levels, 
stronger language on registrar obligations for resellers, and new data 
retention obligations.

■  Enhanced Compliance Tools including broader suspension and termination 
tools, clarification of audit rights and access to information to facilitate 
ongoing investigations, and annual certification requirements.

■   A Registrant Rights and Responsibilities Document that sets out, in clear 
and simple language, the rights and responsibilities that are set out in the 
2013 RAA, such as the types of information that registrants can expect to be 
made available to them about terms and conditions of registrations, fees and 
customer service processes.   The document also emphasizes the registrant's 
role in providing accurate contact information, and responsibilities in 
maintaining domain name registrations. These enumerated rights and 
responsibilities are not comprehensive of all registrant rights and 
responsibilities set out in consensus policies, however this document is 
closely tied to the terms of the 2013 RAA.

■  Registrar Responsibility for Reseller Compliance with all appropriate terms 
of the RAA.

■   Consolidation with the Registry Agreement for New gTLDs.   Where 
appropriate, ICANN and the Registrar NT have agreed to mirror language from the 
Registry Agreement, to allow for contracts that are better aligned.   The New 
gTLD Registry Agreement and the 2013 RAA are anticipated to complement each 
other as Registries and Registrars move towards agreements that better reflect 
the changing marketplace.

■   Proxy and Privacy Provider Interim Requirements.   ICANN and the Registrar 
NT have agreed to interim protections that will be in place for proxy and 
privacy services offered through registrars.   These interim protections will 
require that information is made available on items such as customer service 
processes and when a provider will relay information on the underlying user of 
the domain name registration.   While these are not comprehensive of the 
protections that some have requested to be put in place for proxy and privacy 
providers, these interim protections will provide a more responsible 
marketplace until a formal accreditation program is developed.


Which stakeholders or others were consulted?

The RAA negotiations were initiated because of proposals raised by the law 
enforcement community.   Throughout the negotiations, ICANN and the Registrar 
NT consulted with representatives of law enforcement and the Governmental 
Advisory Committee (GAC) regarding how the 12 law enforcement recommendations 
were implemented.   A summary of how the law enforcement recommendations were 
integrated into the 2013 RAA is available at 
http://www.icann.org/en/news/public-comment/proposed-raa-22apr13-en.htm .   The 
GAC noted its appreciation for the improvements to the RAA that incorporate the 
2009 GAC-Law Enforcement Recommendations, and also noted that it is pleased 
with the progress on providing verification and improving accuracy of 
registrant data and supports continuing efforts to identify preventative 
mechanism that help deter criminal or other illegal activity.

In addition to consultations with law enforcements and the GAC, ICANN has 
hosted public, interactive sessions on the RAA negotiations at the Costa Rica, 
Prague, Toronto and Beijing meetings.   Upon request, representatives from 
ICANN staff also made presentations to the GNSO Council, At-Large working 
groups, various constituencies and stakeholder groups in the GNSO, and law 
enforcement representatives.   In addition, ICANN has posted three versions of 
the RAA publicly, with public comment sought in March 2013 and April 2013.   
The 22 April 2013 public comment was over the proposed final 2013 RAA, which 
included all agreements between ICANN and the Registrar NT.   Nineteen 
commenters participated in the 22 April 2013 comment forum, including 
representatives of the Registrar Stakeholder Group, the ALAC, the Intellectual 
Property Constituency and the Business Constituency.   In support of the 
posting of the proposed final 2013 RAA, ICANN hosted an interactive webinar in 
May 2013 that was attended by more than 100 attendees on the phone and in Adobe 
Connect.

After review of the public comments, ICANN also consulted with the Registrar 
Negotiating Team again to confirm the Registrars' support for identified 
changes.


What concerns or issues were raised by the community?

Throughout the course of the negotiations, concerns have been raised on variety 
of issues within the proposed RAA, which were taken into the account in the 
negotiations.   For example, there was significant concern raised in parts of 
the community regarding over-development of proxy and privacy service standards 
outside of the policy development process.   As a result, ICANN and the 
Registrar NT identified a solution that set out minimum standards for 
registrars to impose on proxy and privacy services offered at registration, 
while setting out a path to community involvement in the development of a 
Proxy/Privacy Accreditation Program.   However, this did not alleviate all 
concerns in this area, nor were all concerns able to be handled in this fashion.

With this last posting of the proposed 2013 RAA, the main areas of concern 
raised were the following:

■  For Whois Accuracy, the IPC, BC and other commenters supported the use of 
pre-resolution verification, as opposed to allowing a 15-day window after 
resolution within which the verification could occur.   This request for 
pre-resolution verification has been raised previously in the negotiations, and 
because of the potential for large change to the domain name registration 
process, as well as the ongoing work to create a new method of dealing with 
gTLD Registration Data, it was determined ?C and explained to the community ?C 
that the pre-resolution verification was not feasible for introduction at this 
time, without further community work and development.

■  Similarly there have been requests for verification of both an email and 
phone number, over registrar and other's concerns that it is not always 
feasible ?C and in some areas of the world nearly impossible ?C to perform 
phone verification.   Further changes in this areas were also deferred in favor 
of the ongoing work on gTLD Registration Data.

■  For registrations through proxy and privacy service providers, multiple 
commenters called for (as they had been calling for throughout the RAA 
development process) verification of the data of the underlying customer.  As 
we previously explained to the community, the forthcoming policy work on a 
Proxy and Privacy Accreditation Program will be place to develop these sorts of 
requirements, as the lines of enforcement will be clearer in that situation.   
In addition, many in the community opposed the introduction of this type of 
requirement at this time.   Similarly, the community is currently not in 
consensus on the mechanism for more explicit requirements for the reveal and 
relay of underlying customer data, and though many have commented that ICANN 
should put those types of requirements in place now, that work has also been 
deferred to the larger community-based policy work on Accreditation. One common 
concern recently raised in regards to the proxy/privacy obligations set forth 
in the 2013 RAA was that we needed to be clearer about the applicability to 
resellers, and ICANN has taken that change on and it is reflected in the 2013 
RAA as approved by the Board.

■  Some commenters raised concerns about the new Registrant Rights and 
Responsibilities document, suggesting that it does not go far enough in 
recognizing more general rights and responsibilities.   Because of the specific 
purpose of the Registrant Rights and Responsibilities specification ?C which is 
to track to the terms of the 2013 RAA ?C we have clarified the title of the 
document.    If the community wishes to produce a broader declaration of the 
rights and responsibilities, nothing within the 2013 RAA would preclude that 
work.

■  Some commenters noted concerns that the amendment processes put in place 
were too onerous for ICANN in the event that it wished to put an amendment in 
place over the objection of the Registrars.   However, ICANN believes that the 
Board-approved amendment process reflected in the 2013 RAA is a balance that 
recognizes the role of policy development in the multistakeholder model, and 
though complex, provides a powerful mechanism in the event it ever needs to be 
invoked.

■  While commenters were generally supportive of the 2013 RAA and the 
advancements that it brings, many of those same commenters noted 
dissatisfaction with the process that led to the development of the 2013 RAA.   
Many were dissatisfied that the negotiations were bilateral, without even an 
opportunity for community observation of the negotiation sessions, let alone 
the ability to propose language during the negotiations.   While it is too late 
to modify the process used previously, it is important to recall that the RAA 
itself did not include any path to negotiation; the process to be used was not 
clear. To help assure that the community will have a voice in future amendments 
to the RAA, the RAA now incorporates specific public comment requirements when 
amendments are under consideration or negotiations have been initiated.

Included here is a summary of some of key concerns raised.   A full summary and 
analysis of the comments on the proposed final RAA (posted at 
http://www.icann.org/en/news/public-comment/report-comments-proposed-raa-21jun13-en.pdf
  [PDF, 188 KB]) has also been considered as part of the decision on the RAA. 
That summary and analysis also identified areas where the 2013 RAA reflects 
modifications in response to comments received.

What significant materials did the Board review?

The Board reviewed the:

■  2013 RAA and incorporated Specifications

■  Summary of Changes between the 2013 RAA and the 22 April 2013 Version

■  Final Clarifications to RAA after Consultation with Registrars

■  22 April 2013 Public Comment Summary and Analysis

■  March 2013 Public Comment Summary and Analysis

■  Summary of Addressing Law Enforcement Recommendations

■  GAC's Beijing Communiqué


What factors the Board found to be significant?

The Board found that many factors significant in reaching this decision.   
First is the intense participation of the Registrar NT and the statements of 
support that have been made by the Registrar community for this 2013 RAA.   
Second, the fact that the 2013 RAA incorporates the 12 GAC-Law Enforcement 
Recommendations, which was the basis for opening the negotiations, as well as 
the GAC's support for the results of the negotiations is a major factor in 
support of the 2013 RAA.   Further, though there are areas where the ICANN 
community would like to see changes to the 2013 RAA, the community statements 
are overwhelmingly in favor of the advancements achieved in this new RAA.   The 
fact that there are paths for the continuation of work on the major areas that 
the community has identified as concerns, including the Expert Working Group on 
the gTLD Registration Data and the work towards a Privacy/Proxy Accreditation 
Program, allows community discussion to continue on some of the more 
challenging issues raised within this negotiation that have not been solved to 
the level that some in the community wish.   The improvements in the 2013 RAA, 
including the enhanced compliance tools, advancements in Whois, clearer 
obligations of resellers, are timely and should be in place prior to delegation 
of new gTLDs, so that all gTLDs entered through the New gTLD Program will be 
covered by these terms.

Finally, the Board found significant that the Registrar Stakeholder Group is 
supportive of the 2013 RAA.

What alternatives were considered by the Board?

Because of the path that the 2013 RAA took to come to the Board, the Board has 
not considered any alternatives other than the alternative of delaying the 
approval of the agreement.  However, the Board did review the community 
recommendations of the items that should be added to or removed from the 2013 
RAA as alternatives.

Are there positive or negative community impacts?

The introduction of the 2013 RAA is expected to have positive impacts, as the 
changes that are going to be put in place with the enhanced obligations are 
expected to result in a maturing of the role of registrars within the DNS.   
The 2013 RAA will give tools to ICANN, Registrars and registrants for clearer 
understanding of obligations, rights and access to information.   The biggest 
risk for the development of negative impacts will come from lack of 
understanding of the new obligations ?C registrants and registrars alike will 
face new requirements.   Educational efforts can help counter these negative 
impacts.


Are there fiscal impacts or ramifications on ICANN (strategic plan, operating 
plan, budget); the community; and/or the public?

The new obligations under the 2013 RAA will impose fiscal ramifications on 
registrars, as they have new operational obligations to meet under the 
agreement and they will need to revise systems and processes to meet these 
obligations.   The 2013 RAA includes a transitional term to give time for 
implementation.   ICANN similarly will have to revise its contractual 
enforcement efforts, which may have a minimal fiscal impact, as the growth of 
the Contractual Compliance Team has already been included with the budget.   
The educational outreach necessary to help assure that Registrars and 
registrants alike understand these new obligations will also impose require 
fiscal resources from ICANN.   There is a potential that increases in registrar 
operational costs will result in increase of prices to consumers, but there is 
no documentation available at this time to support that this will occur.


Are there any security, stability or resiliency issues relating to the DNS?

The 2013 RAA, which includes technical requirements such as support of IDNs and 
DNSSEC, will contribute to the maintenance of the security, stability and 
resiliency of the DNS.


This is an Organizational Administrative Function for which public comment was 
received.