Notes for RAA Briefing Wednesday 20 August 2008

Key URLs:

http://www.icann.org/en/announcements/announcement-18jun08-en.htm

Draft Proposed Changes to Registrar Accreditation Agreement

http://forum.icann.org/lists/raa-consultation/

Index of public comment on proposed changes

http://forum.icann.org/lists/raa-consultation/pdfyYr6BwqsBn.pdf

U.S. Department of Commerce submission on RAA concerns (WHOIS and data escrow)

Introduction for Tim, key points: Today’s briefing represents an opportunity for the ALAC and other user community representatives, notably those whose native language is French or Spanish, to understand proposed changes to the Registrar Accreditation Agreement. The RAA has been in place more than seven years. We may not get another chance to see substantive changes made to the RAA. This briefing is also important because, in the little over a year I have been working on consumer issues as part of the  ICANN at-large, I have come to agree with those who say that many of the most significant consumer and user community issues key issues come down to this agreement.

It’s great that Tim Cole is joining us to talk about the provisions. Note that the RAA revision process goes back almost a year. The ALAC made comments on the RAA after the meeting in San Juan, but has yet to make an official comment on the revisions.

When Tim is done, I want to raise some points of concern. This is the first time the RAA has been translated into French and Spanish, so it’s really important user representatives in those communities get involved. We have a window of about two weeks in which all of us in the at-large have a chance to make comments about the RAA before the final close (in fact, the formal comment period has closed, but we have some extra time because the RAA was not translated until we asked specifically for the translation during the Paris conference). ICANN staff need to make a report to the board so we need to make our comments by the end of August. I’ll address this a little bit at the end.

Tim, can you take us through the four areas and then the amendments, and then I will come back with some user community concerns that come from my own thoughts, from summarizing some of the feedback I have heard, and also from Danny Younger’s document which he filed independently.

(below is a reference as Tim is making his presentation).

1. Enforcement tools
   1. Registrar Audits – Allowing ICANN to conduct site visits and audits of registrars upon at least 15 days notice.
   2. Sanctions & Suspension – Providing for escalated compliance enforcement tools such as monetary sanctions and suspension of registry access.
   3. Group Liability – Preventing "serial misconduct" by registrars when another affiliated (by common control) registrar's RAA is terminated.
   4. Registrar Fees – Revising registrar fee provision to be aligned with recent and current ICANN budgets; assessing interest on late fee payments.
   5. Registrations by Registrars – Creating liability by registrars to ICANN for any registrations created by a registrar for its use in providing Registrar Services.
   6. Arbitration Stay – Eliminating the existing automatic 30-day stay of termination registrars receive by initiating arbitration or litigation to challenge an RAA termination.
2. Registrant protections
   1. Private Registration & Registrar Data Escrow Requirements – Registrars are required to either escrow underlying customer data in the case of private or proxy registrations, or alternatively, give prominent notification that such data will not be escrowed.
   2. Registrant Rights and Responsibilities – Requiring registrars to include on their websites a link to a "Registrant Rights and Responsibilities" document to be created in consultation with the ICANN community.
   3. Contractual Relationships with Resellers – Protecting registrants who are customers of resellers by obligating resellers to follow ICANN policies and requiring that they either escrow privacy/proxy customer data, or alternatively, give prominent notification that such data will not be escrowed.
3. Promoting stable and competitive registrar marketplace
4.  
   1. Accreditation by Purchase – Requiring registrars to notify ICANN upon a change of ownership and to re-certify the registrar's compliance with the RAA.
   2. Operator Skills Training and Testing – Providing for mandatory training of registrar representatives to ensure better registrar understanding of ICANN policies and RAA requirements.
   3. Use of ICANN-Accredited Registrars – Maintaining ICANN's general policy of requiring registries to use ICANN-accredited registrars (in the absence of a reasonable and noted exception).
5. Agreement modernization
6.  
   1. Notice Provision – Streamlining ICANN's obligation to provide notice to registrars of new consensus policies applicable to registrars.
   2. References to the Department of Commerce – Acknowledging ICANN's movement toward independence from the DOC by removing certain references within the RAA to a requirement of DOC approval.
   3. Registrar Data Retention Requirements – Clarifying data retention requirement for registrars to allow for more uniform practices.
      

USER COMMUNITY CONCERNS: (general)

DOC concerns regarding WHOIS – can Tim please elaborate on the US DOC letter 

-- We appreciate the renewed focus on contractual compliance, but the sanctions language is still too lax. “With close to a thousand competitive registrars in the mix, we don’t need a watered-down ‘three-strikes-and-you’re-out’ policy in place.  A single willful fundamental and material contract breach should be sufficient to warrant a loss of accreditation – registrars should either play by the rules or find themselves thrown off the team.” Danny Younger 

-- Under 2C above, the second part of the sentence says:

“or alternatively, give prominent notification that such data will not be escrowed.”

Why should there be any situation in which users’ positive data would not be escrowed?

-- Registrar behavior that at times seems to flout the existence of a contract, yet this behavior is tolerated (pointed out by other members of the user community, also, Danny Younger reference to OECD critique):

Non-compliant registration provisions

The failure to provide complete or correct registration information

Simple uncontactability

Cyberflight-related or other modifications to registrant data after a complaint is filed

Failure to properly implement transfer decisions

Refusal to implement UDRP decisions

Improperly deleting domain names during a proceeding

Improperly unlocking a domain name during a pending proceeding

Changing registration data to reflect the data of the complainant

Engaging in cyber squatting

Bad actors can engage in criminal activity, be “sanctioned,” then go back to the same registrar and do the same thing (pharma example sent to at-large list)

“That which we see in the proposed RAA revisions is not in keeping with the community will as no specific fees are established per violation; neither do we expect the proposed language to deter any registrar from engaging in less-than-admirable behaviors.   Basically, we are at the point where ICANN must make a decisive choice:  it can either continue to coddle its registrars, or it can start kicking butt.  The user community favors the latter approach.” – Danny Younger

CONCLUSIONS

Notes on feedback

n  Should be written down and coordinated, can send to me for a coordinated response (can also send directly to Tim)

n  Late in process at this point – perhaps more effective phrased positively (things that we think are good, things we think are missing that should be included)

n  Not the right time at this point to seek to “start over”

n  Need feeback by end of August