Page History

ICANN-accredited registrars and ICANN commenced a series of direct bilateral negotiations to amend and update the current Registrar Accreditation Agreement (RAA) in November, 2011.   These negotiations are currently underway.'

Update since Prague

 The RAA negotiation teams have resumed negotiations.   Initially, the work centered around reviewing the input received from the ICANN community in Prague.  The negotiation teams have scheduled a series of additional meetings prior to the Toronto Meeting, in an effort to close the gap on some of the key negotiation issues, including:

• Validation/Verification, and whether these new obligations should be completed prior to the domain name’s resolution of the domain name
• Data Retention, and the length of applicable retention periods
• Creation of Privacy/Proxy Accreditation Program, and outlining a framework for moving forward with the program concurrently with the negotiations through a public consultation process to be commenced shortly
• Soliciting Input from the GAC with regard to specific data protection issues, and clarification of the law enforcement recommendations
• Understanding the implementation implications of the proposed changes to the RAA
• Garnering support within the diverse membership of the Registrar Stakeholder Group to the proposed RAA

Since the Prague meeting, ICANN and the Registrars have engaged in six additional negotiation sessions, including two all-day, in-person meetings held in Washington D.C. (one of which was attended by Governmental Advisory Committee members and law enforcement representatives).  The sessions have been supplemented by information and document exchanges between discussions. The negotiations since Prague have largely focused on the key areas of Whois verification and data retention, which are part of the 12 GAC/law enforcement recommendations.  ICANN and the registrars have also continued discussion on the GNSO recommendations and specific requests by ICANN and the registrars, such as supporting DNSSEC and IPv6. 

Other issues are still open for further evaluation and negotiation, including, among others, the proposed changes to the consensus policy language, and the proposal for a revocation clause.  More details are available on the individual meeting reports posted on the WIKI.

...

Current Status  

 In advance of the Prague the Toronto Meeting,on 4 June  on 25 September 2012,  ICANN posted a group of documents on the status of negotiation of amendments to the Registrar Accreditation Agreement (RAA).

These documents note that while ICANN and the Registrars have made progress in the negotiations, the negotiations are not complete and there remain key areas of difference. Of highest priority for ICANN are the areas of Whois verification and data retention requirements, where ICANN and Registrars were not able to agree on certain aspects of the law enforcement recommendations. Because these two areas are so important, ICANN and the registrars were not able to post consolidated, negotiated amendments in advance of the Prague meeting. The RAA Negotiations Summary Memorandum posted on 4 June 2012 explains this more fully; the Draft RAA reflects ICANN's most recent proposal as of 4 June 2012.

These include:

• RAA Toronto Update Memorandum
• RAA Torornto Summary Chart

  Archive of Documents Posted Prior to the Prague Meeting:Recent Developments since the Costa Rica Meeting

• Correspondence delivered from the Registrar Stakeholder Group on the status of the negotiations 
• Law enforcement representatives produced updates to their recommendations with respect to two issues:
  • Data maintenance
  • WHOIS Validation
• Documents published with the 4 June 2012 announcement in advance of the ICANN Prague Meeting:
  • RAA Negotiations Summary
  • Draft RAA
  • Summary Chart
  • Summary of Changes to the 2009 RAA 
  • WHOIS Specification
  • WHOIS Accuracy Specification Program
  • Data Retention Specification
  • Additional Registrar Operation Specification
  • Consensus Policy and Temporary Policy Specification
  • Registrar Information Specification
• Documents submitted by the Registrar Stakeholder Group for the Prague Meeting:
  • Registrar NT Scorecard
  • RAA Critical Issues- Data Retention and WHOIS
  • RAA Critical Issues- Consensus Policies
  • Status of Issues that are the Subject of the LE Recommendations
  • RAA Summary Notes

...

Community Consultation in PragueToronto

At In the Prague Toronto Update on the RAA Negotiations Session scheduled on Monday 25 June 2012 from 11:00-12:30Session scheduled on Monda, October 15, 2012, Staff will seek input on the following:

...

Key Areas for Community Input

 Below we provide some key questions and points of information that we hope to guide the community discussions in advance of community discussions in Toronto – some of which are the same as we posed to the community in Prague. We seek a discussion and input from the community as to where ICANN should hold firm to the proposals within the law enforcement recommendations on Whois verification and data retention issues, and where further negotiation might be required. The pros and cons on these and other issues that should be discussed in a public session are provided below.   We also seek community input on these points.  We also seek to continue discussion on how to assure that, when the new RAA is eventually approved, all Registrars will move to the new agreement.

Specific questions and points to help pinpoint the issues are:

PrePost-resolution Verification
Law enforcement recommends the It is our current understanding that law enforcement representatives are willing to accept post-resolution verification of registrant Whois data before allowing a new domain name registration to resolve.  The Registrars are willing to agree to verify registrants within a certain time after the resolution (such as 5 days), with a requirement to suspend the registration if verification is not successful in that interim within a specified time period. 
Registrars state that: (1) currently, domain names resolve immediately upon registration and changing that practice and delaying resolution for a period of days should be a policy discussion as it dramatically changes the domain name registration market; (2) this attempt to stop the tiny percentage of wrongdoers materially inconveniences the legitimate registration of millions of domain names; and (3) registrants often obtain domain names in order to obtain an email address (associated with the new domain name) so verifying the email addresses prior to registration is not feasible.
Law enforcement states that domain names abuses can be effective even if the domain name is held only a few days and so verification prior to allowing the name to resolve is necessary.However, law enforcement recommends that if registrant Whois data is verified after the domain name resolves (as opposed to before), two points of data (a phone number and an email address) should be verified.

Registrars respond that this approach could have a significant negative impact on customer experience without commensurate law enforcement benefits.  In particular, registrars have argued that: (1) requiring all registrars to perform phone verification (such as through SMS) could greatly impair registrar ability to serve customers outside of their home country and could impose language challenges in conducting phone verification; (2) verification is likely to result in some customer confusion and will almost certainly increase registrar costs and, if both verification methods are required, the requirement could become cost prohibitive or create barriers to registration services; (3) depending on the country or region, some registrars may prefer to use phone verification methods over email verification methods because of concerns of spam filters, etc; (4) wrongdoers will easily pass either verification test, and neither verification test will have a meaningful impact on deterring or combating illegal activity; and (5) given the uncertainty about the costs and benefits of such verification, registrars advocate an either/or approach and to gather data to enable the community to evaluate the relative merit of each one.  

In Toronto, community input is sought on:

• Should the process of registering domain names be changed to perform Whois validation and verification before domain names are allowed to resolve?  
• Will pre-verification address law enforcement’s concern?
• How big of a change is this to the current registration marketplace? 
• What are the costs to Registrars in modifying their systems to allow for pre-verification? 
• What are the costs to registrants?
• How does the fact that registrants often submit a domain name registration request in order to obtain an email address affect the discussion?

 Phone Verification 

...

• (As the agreement currently stands, validation of would take place prior to resolution.) As part of an agreement to support a post-resolution verification model, the negotiation teams have agreed in principle to a review of the Whois verification specification after 12 months of registrar adoption, to determine the effectiveness of the new verification obligations, as well as the launch of work to investigate a pilot program for pre-resolution verification.  In addition, the registrars have proposed the creation of a cross-stakeholder working group to collect data and inform further enhancements and/or policy development.

• Should registrants be required to have and publish a phone number? (Currently the registrar only has to publish telephone numbers for the administrative and technical contacts, not for the Registered Name Holder.) How else might this impact registrants?
• What are the actual technical and financial burdens for Registrars and the Community in verifying phone numbers and/or email addresses or in conducting such verification before resolution of the domain name? 
• Will this encourage the use of proxy services? (Proxy services might also be required to verify the contact details of their customers.)
• What goals will phone verification achieve?
• What are the costs associated with a requirement to verify both telephone and email contact data, and will such a requirement have a meaningful impact on deterring or combating illegal activity?

 Annual Re-verification

The GAC/law enforcement proposal requires annual some form of re-verification of registrant information.   The Whois Reminder Policy has limited effect on Whois accuracy, and some in the community argue that it should be augmented with annual a re-verification .

The Registrars are willing to maintain responsibility for sending Whois reminder policy notices OR verifying information when changed by the registrant.  Registrars state that an annual re-verification requirement imposes significant costs without additional benefit.

requirement. Conversations have now turned to defining the types of events that should trigger a Registrar obligation to re-verify the certain registrant WHOIS information.  Some suggestions of this trigger are:  transfers, bounced emails sent by the registrar, a Whois Data Problem Report Service notification, renewal and if registrar has any information suggesting that the contact information is incorrect. 

Community input is sought on:

• Should re-verification of Whois information be required on a periodic (e.g., annual) basis as opposed to being event driven?  How much of a burden would annual verification impose on legitimate registrants, including those registering large numbers of names?
• Is requiring the cancellation of it appropriate to require registrars to suspend a domain name registration if the annual re-verification cannot be completed too high a penaltyis not completed?  Are the possible unintended consequences, including liability associated with such suspensions, disproportionate? 
• What are the actual technical and financial burdens for Registrars? other possible events that should trigger a requirement to re-verify registrant Whois data?
• What benefits will What goals will this re-verification achieve?

 Data Retention

Law enforcement has requested that all identified data elements be kept for two years past the life of the registration.The Registrars have raised questions regarding their universal ability to retain the data identified by law enforcement, citing various data privacy laws.  Registrars are willing to retain most of the information requested by law enforcement. Registrars state that representatives appear to be willing to accept a dual-tiered retention schedule, requiring some elements such as transaction data can only to be retained for a minimum of six months (not six months after the expiration of the domain name, just six months). Registrars state that this is due to data privacy laws in certain jurisdictions. The Registrars have expressed concerns that registrars in jurisdictions with less-restrictive data protection/privacy regimes will be put at a disadvantage if they are required to maintain registrant data for the full term requested by law enforcement, which is two years past the life of registration, while registrars in other countries may not be able to keep this information for more than 6 months from creation. 

• Is the duration proposed by law enforcement proportionate with their objective, or does it place too high a burden on registrants and Registrars?
• How should ICANN monitor compliance with a two-year plus retention period when many of its accredited Registrars might not be permitted to meet that duration?  Is this counter to a goal of uniformity in contracts across Registrars?
• Does the GAC (or do the governments participating through the GAC) agree with the clarifications proffered by law enforcement?  Can authorities expert in data privacy assist in proposing how ICANN and the Registrars should address the competing legal regimens into a standard that can be uniformly implemented?
• Are any of these requirements already imposed at a national level?

Universal Adoption of RAA

), while other kinds of data would be kept for two years past the life of the registration.  This addresses a key registrar concern that imposing a universal two-year retention requirement would obligate registrars to retain data for longer than it is useable, impose new data retention costs, and create an uneven obligation among registrars, as the data protection/privacy regimes in some jurisdictions would not allow for all data to be maintained for that length of time.  The two-tiered schedule is proposed as a schedule that is more likely to be permitted under various data protection regimes, and to assure a consistent application of obligations under the RAA. 

The possibility, however, always remains that some registrars may find their data retention obligations to be prohibited by even more restrictive laws.  As a result, ICANN and the registrars have discussed various processes under which a registrar might seek a waiver of certain elements of the data retention requirements to the extent that they are in conflict with laws applicable to the registrar.  With the assistance of the Governmental Advisory Committee, ICANN and the registrars are evaluating possible modification of the existing “ICANN Procedure For Handling WHOIS Conflicts with Privacy Law” (at http://archive.icann.org/en/processes/icann-procedure-17jan08.htm) as a basis for this process.  There is concern, however, that as currently drafted, the procedure may only be invoked where a legal proceeding against the registrar has been initiated.  The parties believe that in appropriate circumstances it would be preferable to permit a registrar to invoke the waiver process, and for ICANN to consider a waiver request prior to the initiation of a regulatory or judicial proceeding.

• Is the use of a process like the ICANN Procedure for Handling Whois Conflicts with Privacy Law helpful to identify when registrars should be relieved from certain data retention obligations?  If no, what process should be used?
• What standards could be imposed to invoke the process, short of requiring the initiation of a formal legal or regulatory process?

 Universal Adoption of RAA

 The Registrar Negotiating Team has requested, and ICANN agrees, that it is essential to consider how to require and/or incentivize universal adoption of this new RAA. The accreditation model is based upon having a uniform contract applicable to the principle of uniformity of contracts for all ICANN-accredited Registrars, and .   ICANN and the registrars recognize that those moving to the new RAA will face many new obligations and associated implementation costs.  ICANN and the Registrars have been working hard are striving to create a globally acceptable improved RAA.  How Accordingly, the discussion continues on how can global implementation be best achieved?.

Some ideas that have been suggested either in negotiations or publicly by interested parties:and ICANN seeks community input on these suggestions:

• Provide financial incentive (reduction in both fixed and variable fees) to encourage small and large registrars to migrate to the new agreement.  These financial incentives could be structured as tiered incentives, with greater incentives in the near terms to promote early adoption of the form.  These financial incentives can also be phased out over time, which would require early adoption of the form to fully benefit from these incentives.
• Assure a fixed period of time within which a new round of negotiations over the RAA will not occur, to provide more business certainty.  This would not preclude amendments reached through the processes defined in the RAA.
• Begin limitations on the terms of accreditations and renewals under the 2009 RAA to allow all registrars to move to the new RAA together. 
• Creating Create milestones for the phasing in of certain terms under the new RAA, so that more Registrars would be subject to the new RAA when the terms come into effect.Providing incentives for adoption of the new RAA prior to the expiration of a Registrar’s current RAA.
• Use of a Registrar Code of Conduct process to require certain terms to be followed by all Registrars, regardless of whether they are on the 2009 RAA or the new RAA.
• Requiring use of the new agreement when registering names in new gTLDs.

...