Impact of the 2013 RAA: WHOIS info verification December 12, 2013 | Posted by: Akshay

1. 2013 Registrar
Accreditation
Agreement and
Impact on Resellers
Aman Masjide
Compliance Manager

2. Agenda
• 2013 RAA Introduction
• Obligations of a Reseller
• RAA Specifications impacting Resellers
• Data Retention Specification
• Whois Accuracy Specification
• Privacy/Proxy Specification
• Registrar Data Directory Services (Whois) Specification
• Changes that can be expected by Resellers
• Timelines and Implications
• Questions

3. 2013 RAA Introduction
What is the Registrar Accreditation Agreement?
• Contractual Agreement between a Registrar and ICANN to sell gTLD domains
• Defines and highlights the obligations, business dealing and compliance requirements of an
ICANN Accredited Registrar
Reseller is now defined in the 2013 RAA
• “a person or entity that participates in Registrar's distribution channel for domain
name registrations (a) pursuant to an agreement, arrangement or understanding
with Registrar or (b) with Registrar's actual knowledge, provides some or all Registrar
Services, including collecting registration data about Registered Name Holders,
submitting that data to Registrar, or facilitating the entry of the registration
agreement between the Registrar and the Registered Name Holder.”
Why are Registrars signing the 2013 RAA?
• To sell new gTLDs
• Existing 2009 version of the RAA will not be renewed

4. Obligations of a Reseller
• Shall not display the ICANN or ICANN-Accredited Registrar logo, or otherwise
represent themselves as Accredited by ICANN, unless they have written permission
from ICANN to do so.
• Shall identify the sponsoring registrar upon inquiry from the customer.
• Shall comply with any ICANN-adopted Specification or Policy that establishes a
program for accreditation of individuals or entities who provide proxy and privacy
registration services (a "Proxy Accreditation Program").
• Shall provide customers a link to an ICANN webpage detailing registrant
educational information
• Shall publish on their website(s) and/or provide a link to the Registrants' Benefits
and Responsibilities Specification
• Shall comply with requirements to ensure Registrar is not in breach of this
Agreement.

5. RAA Specifications Impacting Resellers
Data Retention Specification

6. Data Retention Specification
Data to be Retained during registration and 2 years post deletion:
• Full Name, Title (if applicable), postal address, email address, phone number, fax of the
Registrant, Admin, Billing, Technical contact and customer
• Types of domain name services purchased for use in connection with the domain
registration service by the Registrant
•“Credit Card on file” – to the extent collected by the Registrar, transaction ID, or other
recurring payment data
Data to be retained for at least 180 days
• All Transaction Details
• Log Files
• Billing Records
• Communication Source and destination information (depending on method of
transmission), without limitation, for communication between Registrar and Registrant
• Source IP address, http headers
• Telephone, text or fax number
• Email addresses
• Skype handle or IM identifier
• Log files of timestamps, time zones of communication and sessions, including initial
registration

7. Data Retention Specification
Impact on Resellers
•
The obligation of data retention passes on to Resellers
• All communication with the Registrant/Customer need to maintained by the
Resellers with appropriate logs
• To "ensure" Reseller compliance Registrars are suggested by ICANN to do the
following:
a) Make the data retention obligations part of the Registrar's Agreement with the Reseller/
Reseller-Master Agreement
b) Come up with an Audit Program to see if resellers are compliant with this requirement
c) Enforce compliance on resellers if found to be non-compliant

8. RAA Specifications Impacting Resellers
Whois Accuracy Specification

9. Whois Accuracy Specification
• Verification of Email OR Phone of Registrant Contact and Customer (if different)
• Email verification through automated code/link authentication
• Calling or sending a unique code via SMS
• Validation
• Validate the presence of data for all fields required under Subsection 3.3.1
• Validate that all email addresses are in the proper format according to RFC 5322 (or its
successors)
• Validate that telephone numbers are in the proper format according to the ITU-T E.164
notation for international telephone numbers (or its equivalents or successors)
• Validate that postal addresses are in a proper format for the applicable country or
territory as defined in UPU Postal addressing format templates, the S42 address templates
(as they may be updated) or other standard formats
• What must a Registrar do upon failed verification
• Either validate manually;
• Or Suspend the registration till the verification is completed
• If customer information is not verified, Registrar should attempt to manually verify. No
suspension action on domains registered required

10. Whois Accuracy Specification
• The Verification and Validation process must be implemented within 15 days, for
• New Registrations
• Transfer ins
• Contact modifications (+ verification required in cases of ‘Move’)
• Association of any contact with a gTLD domain registration
• Once a contact is validated and verified, it need not be done again and can be
applied to subsequent domain registrations
• If Registrar has any information
suggesting that the contact information is
inaccurate (post verification), a re-verification and re-validation is required to be
completed within 15 days of receiving such information Or Suspend the registration
till the verification is completed
• e.g. Bounceback messages received for WDRP emails is an indicator

11. Whois Accuracy Specification
Impact of the Verification and Validation Requirement
• Automatic process to verify customer accounts and domain
contact email
addresses is being built
• Resellers will have to ensure that customers will be filling accurate contact
details during signup and comply with the verification requirements
• Validation checks will be implemented on the Supersite
• API impact analysis is still underway and shall be given to the Resellers
• Instead of suspending domains on failed verification, we will redirect the
domain to an instruction page
• Even if a domain name has Privacy Protection enabled, the underlying contact
will be verified

12. RAA Specifications Impacting Resellers
Privacy / Proxy Services Specification

13. Privacy / Proxy Services Specification
• Until ICANN comes up with a proper Privacy and Proxy Accreditation Program, not
expected to be implemented before 2017, Registrars and Resellers must agree to
follow the Specifications of this policy.
• Registrars must ensure that they prohibit Resellers to use any Privacy/Proxy
registration services that do not follow the requirements of this policy
• Disclosure on PP website:
• Identity of PP provider
• Process of revealing underlying customer data
• Process of transferring a domain name that is PP enabled
• Circumstances under which the PP service may be disabled by PP provider
• Process for PP customers to terminate the service and displaying the underlying
customer information on the WHOIS
• Description of customer service handling processes available to Registrants regarding PP
services, including a process for submitting complaints and resolving disputes
• A copy of the PP service Agreement

14. Privacy / Proxy Services Specification
• Obligation to relay correspondence:
• Forward all allegations of malicious/illegal conduct to the PP customer within 5 days
• Escrow of Customer information
• PP contact details
• Underlying customer information
• Abuse POC and duty to investigate Reports of abuse:
• Dedicated abuse POC email address and phone number to be displayed on the website
• 24x7 abuse desk
• Well-founded reports to be investigated within 24 hours and take appropriate action
according to its AUP
• No action to be taken in contravention of applicable laws
• Should disclose on website, procedure of receipt, handling and tracking abuse reports
• Records of abuse reports should be maintained for a minimum of 3 years

15. RAA Specifications Impacting Resellers
Registrar Data Directory Services (Whois) Specification

16. Whois Specification
• Registrar will operate WHOIS service via Port 43 in accordance with RFC 3912 and
free web based service for all thin TLDs
• Each data object shall be represented by a set of key/value pairs. Basically similar to
THICK registry Whois format that is fetched from the Registry.
• All previously reseller branded Whois outputs for thin TLDs will be removed.
• Whois output will show Reseller Brand Name as set in their respective control
panels.
• Registrar will have to show their respective abuse email and phone contacts.

17. What we’re doing to comply with the RAA

18. Changes that can be expected by Resellers
• Change to the Reseller-Master Agreement to accommodate ICANN specific
obligations.
• These obligations should be passed on to your sub-resellers contractually.
• System changes to accommodate the specifications discussed in the
previous slides
• New compliance mechanisms will be adopted by ResellerClub to conduct
Audits for resellers to ensure their compliance with the data retention
specification, ICANN obligations and privacy protection service specification.
• Upon signing the 2013 RAA Resellers can expect a whole new bunch of
TLDs available in the system for them to sell.

19. Timelines and implications
When must Registrars sign the 2013 RAA?
• Registrars have already started signing the 2013 RAA and upgrading their systems
• Some Registrars will have to sign when their existing 2009 agreement expires which
could be somewhere in the first quarter of 2014
When will ResellerClub sign the 2013 RAA?
• ResellerClub intends to sign the Agreement within a couple of weeks.
• However, ResellerClub will not enforce the requirements of the specifications discussed
before Jan 1 2014.

20. Questions
compliance@resellerclub.com