ICANN ICANN Email List Archives


<<< Chronological Index >>>    <<< Thread Index >>>

Comments on ICANN RAA Improvements 2010

  • To: raa-improvements2010@xxxxxxxxx
  • Subject: Comments on ICANN RAA Improvements 2010
  • From: jerry1upton@xxxxxxx
  • Date: Wed, 28 Jul 2010 21:58:48 -0400

Please accept the below and attached comments from the MessagingAnti-Abuse 
Working Group, www.maawg.org/.
Jerry Upton 
Executive Director


From:            MessagingAnti-Abuse Working Group (MAAWG)
Date:            July28, 2010
Subject:            Commentson ICANN Report RAA-Improvements-Proposal-28May10
Thank you for the opportunityto submit comments on the Initial Report on 
Proposals for Improvements to theRAA 
The Messaging Anti-AbuseWorking Group is an international non-profit 
industry-lead organization foundedto fight all forms of abuse, such as 
phishing, botnets, fraud, spam, virusesand denial-of-service attacks. Drawing 
technical experts, researchers and policy specialists from abroad base of 
Internet Service Providers and Network Operators representing overone billion 
mailboxes, key technology providers, academia and volume senderorganizations, 
the multi-disciplinary approach at MAAWG (http://www.maawg.org) includes 
education,advise in public policy and legislation, development of industry 
bestpractices, guidance in development of industry standards, and 
facilitatingcollaboration. We view the domain registration system as a critical 
componentof the Internet infrastructure within which our members work, a fact 
reflectedin the existence and work performed by the MAAWG registrar 
subcommittee.Responsible registrars play a unique and critical role in 
preventing andresponding to online abuse.
MAAWG is thus pleased to see ICANN’s interest in improving the 
currentRegistration Accreditation Agreement (RAA). We commend you, all those 
whosubmitted proposed changes, and all those who worked so hard on the 153 
page“Initial Report on Proposals for Improvements to the RAA” (hereafter 
referredto as the Initial Report).
We view the key question faced by the committee that produced the 
InitialReport, and the key question now facing ICANN itself, as being: Given 
over ahundred suggested amendments and limited staff and community resources, 
whichof the proposed changes should properly have the highest priority 
forimplementation in the next version of the RAA? 
The initial reporthighlighted twelve high priority items (we will refer to 
these as HP1 throughHP12) and ten medium priority items (MP1 through MP10), 
with the remainder ofthe items falling in a low priority category by default. 
Since medium and lowpriority items will have a reduced likelihood of being 
immediately incorporatedinto a revised version of the RAA, it is critical that 
the most urgent itemsremain in the high priority category. We also assume that 
the high prioritylist will not remain meaningful and useful if allowed to grow 
beyond itsinitial size of twelve items. 
Reviewing the list of twelve high priority items onpages 18 and 19, we concur 
with the authors of the Initial Report that itemsHP2 through  HP11 from the 
high priority list should properly receive toppriority as potential amendments 
for incorporation into the next version of theRAA. These are “common sense” 
items that we believe most would already expectto be part of the RAA.
HP2:    Maliciousconduct – registrar duty to investigate 
HP3:    Designationof technically competent point of contact on malicious 
conduct issues,available on 24/7 basis 
HP4:    Registrardisclosure of privacy/proxy services made available in 
connection withregistration; and
responsibility of registrar for compliance by such services 
HP5:    Obligationsof privacy/proxy services made available in connection with 
registration re dataescrow; Relay 
function; Reveal function 
HP6:    Registrarresponsibility for cancellation under appropriate 
circumstances ofregistrations made by other 
privacy/proxy services for noncompliance with Relay and Reveal 
HP7:    Definecircumstances under which registrar is required to cancel 
registration forfalse Whois data 
HP8:    RequirePCI compliance in registration process 
HP9:    Define“reseller” and clarify registrar responsibility for reseller 
HP10:    Requiregreater disclosure of registrar affiliates/multiple 
HP11:    Requiregreater disclosure of registrar contact information, 
information on form ofbusiness organization, 
officers, etc. 
With respect to the remainingtwo items that might ultimately comprise a 
twelve-item high priority slate, webelieve that items MP3 and MP5 from the 
medium priority list should be elevatedfrom the medium priority list to the 
high priority list 
(if necessary displacing current high priority items HP1 and HP12 to keep 
thesize of the high priority list manageable).
It is our belief that HP1(prohibiting registrar cyber squatting), and HP12 
(clarifying registrarresponsibilities in connection with UDRP proceedings), 
while unquestionablyimportant, are primarily focused on intellectual property 
issues, and willlikely have lower immediate operational impact when it comes to 
controllingmessaging abuse than MP3 (service level agreements on Whois 
availability) andMP5 (expand scope of authority to terminate accreditation).
We also note that while manyproposed changes to Whois proxy/privacy services 
were given high priority(e.g., see HP4 through HP6), matrix item 5.11 (Restrict 
Proxy/Privacy Servicesto only non-commercial purposes) did not get prioritized 
in the Initial Report.We believe this is an oversight that should be rectified 
by raising matrix item5.11 to medium priority. By restricting proxy/privacy 
registrations to onlynon-commercial registrations, the community can insure 
that commercial domainname registrations remain transparent (and commercial 
registrants remainpublicly accountable), while 
non-commercial registrants with a well-founded basis for redacting theircontact 
information (such as individuals or 
non-commercial organizations targeted by stalkers or abusers) can 
registerdomain names while remaining protected from potential harassment.
The RAA only providesprotections to registrants and Internet users insofar as 
its provisions areenforced. Hence it is essential that every provision be 
written to permitmeaningful verification of compliance, and that ICANN develop 
and implement itscompliance verification strategy in parallel with the RAA 
modifications. Forexample, in item HP7, the RAA needs a time limit for 
registrars to act oninvalid Whois information, so ICANN can verify both whether 
a registrarresponds and whether the response is timely. For those items that 
requireregistrars to provide contacts or other information, it would be very 
desirablefor ICANN to publish the information provided by the registrars and 
the lasttime it was verified. This would include, for example, item HP3, the 
24/7technical contact, and item HP11, the registrar's contacts, officers, 
andbusiness information.
MAAWG appreciates theopportunity to offer comments on this important work, and 
we would welcomefurther discussions if you have any questions about our 
Jerry Upton
Executive Director, MAAWG 


Attachment: MAAWG Comments ICANN-RAA.pdf
Description: Adobe PDF document

<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy