You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 53 Next »

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.'

Pre-Toronto Update

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. 

More details are available on the individual meeting reports posted on the WIKI.

Negotiation Goals/Objectives 

During the ICANN Dakar Meeting, ICANN and the Registrar Stakeholder Group announced their agreement to commence negotiations on possible amendments to the RAA to address recommendations made by law enforcement agencies and the GNSO, provide increased protections for registrants, to enhance  security generally, and to increase predictability for all stakeholders.  

At its meeting in Dakar, the ICANN Board directed these negotiations to commence immediately, with the goal of reaching agreement on amendments that are “in the global public interest with the twin goals of registrant protection and stability...” for consideration by the ICANN Board at the Costa Rica Meeting.  

ICANN and the Registrars have agreed to discuss the following topics in these negotiations: 

  • The law enforcement RAA recommendations, including as formulated by law enforcement in its proposed code of conduct;
  • The “High Priority” recommendations from the joint GNSO/ALAC RAA Drafting Team’s Final Report (see Final Report);
  • To the extent time permits, the  “Medium Priority” recommendations from the joint GNSO/ALAC RAA Drafting Team’s Final Report;
  • Other topics that would advance the goals of registrant protection, DNS stability, and increased predictability for all stakeholders.

Background

In 2009, the GNSO Council embarked on a collaborative process with the At Large Advisory Committee regarding the RAA.  As part of this process, a joint GNSO/ALAC drafting team was formed (known as the RAA Drafting Team or, “RAA DT”) to consider various proposals for improvements to the RAA. The RAA DT reviewed proposals from the law enforcement community, the Intellectual Property Constituency, as well as other stakeholders.  The RAA DT published a Final Report on 18 October, 2010, that identified potential topics to be addressed in an amended RAA.  The RAA DT also propose several  next steps for the GNSO Council to consider in determining whether to recommend a new form of RAA.   

Prior to Dakar, Staff published a Discussion Paper on the Next Steps for the RAA that recommended the immediate commencement of bilateral negotiations with the Registrars.   At Dakar, law enforcement representatives and other stakeholders debated the need for additional amendments to the RAA. 

In Dakar, the ICANN Board adopted a resolution (2011.10.28.31) <http://www.icann.org/en/minutes/resolutions-28oct11-en.htm#7> acknowledging that the effort to evolve the RAA is an important element in a program to protect registrants and safeguard the stability of a single interoperable Internet.  The resolution called for immediate negotiations and called on the negotiating teams to publish proposed amendments for consideration at ICANN’s meeting in Costa Rica in March 2012. The Board resolution called on the negotiating teams to address of law enforcement and GNSO working group recommendations as well as other topics that would advance the twin goals of registrant protection and DNS stability.  The ICANN Board also directed Staff to prepare an Issues Report with respect to any remaining items suited for a PDP.

The Registrars Stakeholder Group and ICANN announced in Dakar the immediate commencement of negotiations on the RAA.  These negotiations will occur regularly with the goal of issuing agreed amendments to the RAA for consideration by the ICANN Board.

Current Status  

 In advance of the Toronto Meeting, on 24 September 2012,  ICANN posted a group of documents on the status of negotiation of amendments to the Registrar Accreditation Agreement (RAA). These include:

  Archive of Documents Posted Prior to the Prague Meeting:

More Information

Community Consultation in Toronto

In the Toronto Update on the RAA Session scheduled on Monday, October 15, 2012, Staff will seek input on the following:

 _________________________________________________

AGENDA FOR PUBLIC MEETING

Key Areas for Community Input

Below we provide some key questions and points of information in advance of community discussions in Toronto – some of which are the same as we posed to the community in Prague. We 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:

Post-resolution Verification
It is our current understanding that law enforcement representatives are willing to accept post-resolution verification of registrant Whois data, with a requirement to suspend the registration if verification is not successful within a specified time period.  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 verification before domain names are allowed to resolve? (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? 
  • 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?

Re-verification

The GAC/law enforcement proposal requires 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 a re-verification 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 it appropriate to require registrars to suspend a domain name registration if the annual re-verification is not completed?  Are the possible unintended consequences, including liability associated with such suspensions, disproportionate? 
  • What are other possible events that should trigger a requirement to re-verify registrant Whois data?
  • What benefits will re-verification achieve?

 Data Retention

Law enforcement representatives appear to be willing to accept a dual-tiered retention schedule, requiring some elements such as transaction data to be retained for a minimum of six months (not six months after the expiration of the domain name), 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 the principle of uniformity of contracts for all ICANN-accredited Registrars.   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 are striving to create a globally acceptable improved RAA.  Accordingly, the discussion continues on how can global implementation be best achieved.

Some ideas that have been suggested 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. 
  • 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.
  • 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.

If you have general feedback you'd like to provide, please provide them by submitting comments below.

 

To Leave a Comment on This Page:  Any user logged into Confluence will see an "Add Comment" button at the bottom of this page, which can be used to leave a comment.  To log in, click the "Log In" button on the gray control bar toward the top of the page, and enter your user name and password.  If you do not have a user name and password, please e-mail margie.milam@icann.org with "Log In" in the subject line.  

  • No labels