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

[Bruce Tonkin]

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.