Accord d’accréditation des registrars

Introduction

This docu­ment pro­vides some « plain lan­guage » sum­ma­ri­za­tion of terms rela­ted to regis­trant rights and res­pon­si­bi­li­ties as set out in the regis­trar Accreditation Agreement (RAA), for post­ing on Registrar web­sites. While some of the terms inclu­ded here do not spe­ci­fi­cal­ly refer to regis­trants, those terms are inclu­ded because of the poten­tial import to unders­tan­ding registrar/registrant rela­tions. This docu­ment also sum­ma­rizes regis­trant rights and res­pon­si­bi­li­ties that arise within ICANN Consensus Policies and spe­ci­fi­ca­tions, as those poli­cies and spe­ci­fi­ca­tions are incor­po­ra­ted into the RAA.’
The sum­ma­ri­za­tion of terms within this docu­ment do not over­ride or replace the terms set forth in the RAA or within those spe­ci­fi­ca­tions or poli­cy.

Preamble

In order to regis­ter a domain name, a Registered Name Holder (also known as a Registrant) has to use the ser­vices of an ICANN-accre­di­ted Registrar. In order to become an ICANN-accre­di­ted Registrar, the Registrar must enter into a contract with ICANN, refer­red to as the Registrar Accreditation Agreement or the RAA. The RAA sets out various rights and res­pon­si­bi­li­ties for Registrants, and Registrants have addi­tio­nal rights and res­pon­si­bi­li­ties that are set forth in sepa­rate ICANN poli­cies and spe­ci­fi­ca­tions that the Registrars agree to fol­low.
The RAA and the rela­ted poli­cies are draf­ted in very spe­ci­fic, often legal ter­mi­no­lo­gy. In order to help Registrants bet­ter unders­tand the rights and res­pon­si­bi­li­ties that come along with the regis­tra­tion of a domain name, these rights and res­pon­si­bi­li­ties are being sum­ma­ri­zed and pre­sen­ted within a single docu­ment. The sum­ma­ries pro­vi­ded here do not over­ride or replace the actual terms as writ­ten in the RAA or the rela­ted poli­cies and spe­ci­fi­ca­tions.

RAA Terms of Interest

As the RAA is bet­ween ICANN and a Registrar, no one else – inclu­ding a Registered Name Holder – may sue ICANN or the Registrar to claim a breach of the RAA.
Registrars may not make claims that they can pro­vide regis­trants with super­ior access to any rele­vant TLD in com­pa­ri­son to other Registrars.
Some of the Registrar obli­ga­tions are dependent upon Registered Name Holders ful­filling cer­tain res­pon­si­bi­li­ties, par­ti­cu­lar­ly as it relates to pay­ment of regis­tra­tion fees, sub­mis­sion of requi­red data points to the Registrars, and sub­mis­sion of accu­rate data and time­ly updates to that requi­red data. Registrars also have spe­ci­fic items on which they must pro­vide notice to Registered Name Holders, inclu­ding noti­fi­ca­tions of the end of a regis­tra­tion term, use of Registered Name Holder’s Personal Data, and notices regar­ding escro­wing of data for domain names regis­te­red through pri­va­cy or proxy regis­tra­tion ser­vices, as well as the post­ing of fees for the reco­ve­ry of regis­te­red names.
Registrar Submission of Data to Registry Operators
For each rele­vant TLD, Registrars must sub­mit cer­tain data points rela­ting to each Registered Name within a TLD :

• The name of the Registered Name being regis­te­red (3.2.1.1);
• The IP addresses of the pri­ma­ry name­ser­ver and secon­da­ry nameserver(s) for the Registered Name (3.2.1.2);
• The cor­res­pon­ding names of those name­ser­vers (3.2.1.3);
• Unless auto­ma­ti­cal­ly gene­ra­ted by the regis­try sys­tem, the iden­ti­ty of the Registrar (3.2.1.4);
• Unless auto­ma­ti­cal­ly gene­ra­ted by the regis­try sys­tem, the expi­ra­tion date of the regis­tra­tion (3.2.1.5); and
• Any other data the Registry Operator requires be sub­mit­ted to it (3.2.1.6).

Registered Name Holders are nor­mal­ly requi­red to pro­vide the Registrar with infor­ma­tion rela­ting to name­ser­vers (3.2.1.2 – 3), and there may be addi­tio­nal data requi­red under Section 3.2.1.6 that the Registered Name Holder must pro­vide. If the Registered Name Holder pro­vides an update on these data points, the Registrar has five (5) days to pro­vide the update to the Registry Operator.
Whois Data
Registrars are requi­red to have an inter­ac­tive web page and port 43 Whois ser­vice that is avai­lable to the public to que­ry free of charge. The RAA spe­ci­fies cer­tain data points that must be pro­vi­ded in res­ponse to a que­ry :

• The Registered Name (3.3.1.1);
• The names of the pri­ma­ry name­ser­ver and secon­da­ry nameserver(s) for the Registered Name (3.3.1.2);
• The iden­ti­ty of Registrar (which may be pro­vi­ded through Registrar’s web­site) (3.3.1.3);
• The ori­gi­nal crea­tion date of the regis­tra­tion (3.3.1.4);
• The expi­ra­tion date of the regis­tra­tion (3.3.1.5);
• The name and pos­tal address of the Registered Name Holder (3.3.1.6)
• The name, pos­tal address, e‑mail address, voice tele­phone num­ber, and (where avai­lable) fax num­ber of the tech­ni­cal contact for the Registered Name (3.3.1.7); and
• The name, pos­tal address, e‑mail address, voice tele­phone num­ber, and (where avai­lable) fax num­ber of the admi­nis­tra­tive contact for the Registered Name (3.3.1.8).

These data points are com­mon­ly refer­red to as Whois data. As dis­cus­sed below, Registered Name Holders are requi­red to pro­vide a Registrar with time­ly updates to Whois data for a Registered Name. Upon recei­ving the update, a Registrar is to « prompt­ly » update the Whois data. Registrars may contract out the main­te­nance of the public que­ry func­tion.
The RAA allows Registrars to pro­vide bulk access to Whois data to third par­ties. When pro­vi­ding bulk access or access to the Whois data through the public que­ry func­tion, the Registrar is requi­red to res­trict access for high volume que­ries or other res­tric­tions on uses of Whois data as spe­ci­fied in the RAA, inclu­ding mar­ke­ting acti­vi­ties and mass soli­ci­ta­tions. If a Registrar contracts the public func­tion que­ry to an out­side par­ty, the Registrar must require any contrac­tor pro­vi­ding the port 43 ser­vice to impose the same res­tric­tions on access to and use of the Whois data.
Communications with Registered Name Holders
Registrars are requi­red to main­tain records of all com­mu­ni­ca­tions with Registered Name Holders, as well as records of infor­ma­tion pro­vi­ded to Registry Operators.
Escrow of Registered Name Holder Data
A Registrar is requi­red to main­tain a data­base of all Whois data for all Registered Names regis­te­red through the Registrar’s accre­di­ta­tion, as well as all data the Registrar sub­mits to the Registry Operator. In addi­tion, the Registrar must include in the data­base the name and (where avai­lable) pos­tal address, e‑mail address, voice tele­phone num­ber, and fax num­ber of the billing contact for each Registered Name.
In some ins­tances, a regis­trant may choose to limit the amount of per­so­nal infor­ma­tion that a Registrar makes avai­lable in a Whois que­ry. To do so, the name may be regis­te­red through a pri­va­cy ser­vice (allo­wing a regis­trant to conceal per­so­nal iden­ti­fying infor­ma­tion and often repla­cing it with the infor­ma­tion of the pri­va­cy ser­vice). Customers may also choose to regis­ter names through a proxy ser­vice, where the proxy ser­vice is the Registered Name Holder, and the proxy ser­vice licenses the use of the domain name to the cus­to­mer. In that situa­tion, the proxy ser­vice, as the Registered Name Holder, has its infor­ma­tion lis­ted for most or all requi­red data points.
When a Registered Name is regis­te­red through a pri­va­cy or proxy regis­tra­tion ser­vice, that affects the infor­ma­tion that is pla­ced in the data­base, and a Registrar must do one of two things : The Registrar must either (1) include in the data­base the name and pos­tal address, e‑mail address, and voice tele­phone num­ber pro­vi­ded by the cus­to­mer in connec­tion with each regis­tra­tion, even when a pri­va­cy or proxy regis­tra­tion is used ; or (2) at the time that a cus­to­mer elects to use a pri­va­cy or proxy regis­tra­tion ser­vice, dis­play a notice that the customer’s data is not being escro­wed. When a customer’s data is not being escro­wed, only the contact infor­ma­tion asso­cia­ted with the pri­va­cy or proxy regis­tra­tion ser­vice will be escro­wed. If a customer’s data is not escro­wed, and only the infor­ma­tion of the proxy or pri­va­cy ser­vice is main­tai­ned in the data­base, in the event of Registrar or Registry fai­lure future notices may only be sent to the contact infor­ma­tion within the data­base.
Registrar Business Dealings with Registrants
The RAA imposes many requi­re­ments on a Registrar’s busi­ness dea­lings, inclu­ding its dea­lings with Registered Name Holders.
A regis­trar may not acti­vate a Registered Name until it receives rea­so­nable assu­rance from the Registered Name Holder that the regis­tra­tion fee will be paid.
The RAA sets forth actions the Registrar may take at the conclu­sion of the regis­tra­tion per­iod if a Registered Name Holder has not pro­vi­ded consent to renew the regis­tra­tion, inclu­ding the Registrar can­cel­ling the regis­tra­tion at the end of the cur­rent regis­tra­tion term. If the Registered Name Holder did not consent to rene­wal, the Registrar must make sure that a Registered Name is dele­ted from the Registry data­base within 45 days of the end of the regis­tra­tion term.
This right for the Registrar to can­cel the regis­tra­tion and the obli­ga­tion to the delete the domain name is not abso­lute. Section 3.7.5.1 of the RAA sets forth a list of poten­tial « exte­nua­ting cir­cum­stances, » that, if exist, allows the Registrar to renew the domain name even without the consent of the Registered Name Holder. These cir­cum­stances include the Registered Name being sub­ject to a UDRP action, court order, ban­krupt­cy pro­cee­ding, or billing dis­pute, among other items. The Registrar must keep a record of rea­sons why the Registrar rene­wed a regis­tra­tion without the consent of a Registered Name Holder.
Registrars have to pro­vide each new regis­trant with notice of the Registrar’s dele­tion and auto-rene­wal poli­cies. If the Registrar’s dele­tion poli­cy changes during the time of the regis­tra­tion agree­ment, the Registrar has to make efforts to inform the regis­trants of those poli­cy changes. Details of the dele­tion and auto-rene­wal poli­cies have to be dis­played on any web­site the Registrar ope­rates for domain name regis­tra­tion and rene­wal, and the Registrar should also state on those sites any fee that will be char­ged for the reco­ve­ry of a domain name during the Redemption Grace Period (the 30 day per­iod of time during which the name is in « Pending Delete » sta­tus with the Registry).¹
If a Registered Name is the sub­ject of a UDRP dis­pute at the time of dele­tion or expi­ra­tion of the regis­tra­tion, the UDRP com­plai­nant has the right to renew (or res­tore, in the case of a dele­tion) the domain name. If the com­plai­nant renews or res­tores the name, the Registrar must place the name in a HOLD or LOCK sta­tus,² and must modi­fy the Whois infor­ma­tion to show that the name is sub­ject to dis­pute. Section 3.7.5.7 of RAA also pro­vides for a right for the ori­gi­nal domain name regis­trant to reco­ver or renew the name in the event the UDRP com­plaint is ter­mi­na­ted without deci­sion, or the UDRP com­plaint is deci­ded in favor of the ori­gi­nal domain name regis­trant.
The Registrar/Registered Name Holder Agreement
Registrars are requi­red to enter into elec­tro­nic or paper regis­tra­tion agree­ments with all Registered Name Holders. According to the RAA, the Registrar/Registered Name Holder Agreement must include – at mini­mum – the fol­lo­wing items (as sta­ted at Sections 3.7.7.1 – 12 of the RAA):

• The Registered Name Holder must pro­vide « accu­rate and reliable contact details » and must « prompt­ly cor­rect and update them » during the regis­tra­tion term. The details requi­red are sta­ted in Section 3.7.7.1.: « the full name, pos­tal address, e‑mail address, voice tele­phone num­ber, and fax num­ber if avai­lable of the Registered Name Holder ; name of autho­ri­zed per­son for contact pur­poses in the case of an Registered Name Holder that is an orga­ni­za­tion, asso­cia­tion, or cor­po­ra­tion ; and the data ele­ments lis­ted in Subsections 3.3.1.2, 3.3.1.7 and 3.3.1.8. »
• If a Registered Name Holder inten­tio­nal­ly pro­vides inac­cu­rate or unre­liable infor­ma­tion, inten­tio­nal­ly fails to prompt­ly update the infor­ma­tion, or fails to respond over fif­teen (15) days to Registrar inqui­ries about the accu­ra­cy of the contact details, the Registered Name Holder will be in mate­rial breach of the agree­ment and the regis­tra­tion may be can­cel­led.
• Whoever is lis­ted as the Registered Name Holder must pro­vide full contact infor­ma­tion, and is the Registered Name Holder of record. Sometimes a Registered Name Holder may regis­ter a domain name and then allow ano­ther per­son to use the domain name (such as a web­site desi­gner regis­te­ring a domain name for a client). If this hap­pens, and the per­son actual­ly using the name did not enter into the Registrar/Registered Name Holder Agreement (refer­red to as a « third par­ty » in the RAA), the Registered Name Holder could be accoun­table for wrong­ful use of the domain name by the third par­ty. This will hap­pen if the Registered Name Holder is pro­vi­ded with « rea­so­nable evi­dence of actio­nable harm » from the third party’s use of the domain name. In that situa­tion the Registered Name Holder will « accept lia­bi­li­ty for harm cau­sed by wrong­ful use of the Registered Name, » unless the Registered Name Holder dis­closes the user’s iden­ti­ty and cur­rent contact infor­ma­tion.
• The Registrar must pro­vide notice of how it intends to use data pro­vi­ded by the Registered Name Holder and who will recei­ved the Registered Name Holder’s data. The Registrar must also pro­vide notice of how Registered Name Holders may access and update data. Additionally, the Registrar must iden­ti­fy which data points the Registered Name Holder must pro­vide to the Registrar, and what infor­ma­tion can be pro­vi­ded on a volun­ta­ry basis. The Registered Name Holder must consent to all of these data pro­ces­sing terms.
• If a Registered Name Holder pro­vides the Registrar with Personal Data on behalf of any per­son who did not enter into the Registrar/Registered Name Holder Agreement (the « third par­ty » dis­cus­sed above), the Registered Name Holder must confirm that it (1) pro­vi­ded those third-par­ty indi­vi­duals with the same data pro­ces­sing notices that the Registrar pro­vides, and (2) recei­ved the same consents from the third par­ty regar­ding the Registrar’s data pro­ces­sing terms.
• A Registrar may only pro­cess the Registered Name Holder’s data as sta­ted in the data pro­ces­sing notices des­cri­bed above.
• A Registrar has to agree that it will take rea­so­nable pre­cau­tions to pro­tect the Registered Name Holder’s data from « loss, misuse, unau­tho­ri­zed access or dis­clo­sure, alte­ra­tion, or des­truc­tion. »
• Registered Name Holders must represent that : « to the best of the Registered Name Holder’s know­ledge and belief, nei­ther the regis­tra­tion of the Registered Name nor the man­ner in which it is direct­ly or indi­rect­ly used infringes the legal rights of any third par­ty. » This means that the Registered Name Holder must represent to the Registrar that the domain name is not being regis­te­red for use in a way that would vio­late the legal rights of others. An example of this « infrin­ge­ment » could be a regis­tra­tion of a domain name that vio­lates a tra­de­mark or copy­right held by someone that is not the Registered Name Holder.³
• If there is a dis­pute in connec­tion with the use of the regis­te­red name, the Registered Name Holder must agree to juris­dic­tion of the courts in at least one of two places : where the Registrar is loca­ted (often sta­ted on the web­site or in the Registrar/Registered Name Holder Agreement) or the « Registered Name Holder’s domi­cile. » « Domicile » is a word with legal­ly-spe­ci­fic mea­ning, but typi­cal­ly will be the loca­tion the Registered Name Holder pro­vides to the Registrar in the requi­red Personal Data. Agreeing to juris­dic­tion means that the Registered Name Holder agrees that the courts in those loca­tions have the power to decide these types of cases.⁴
• The Registered Name Holder must agree that its regis­tra­tion is sub­ject to « sus­pen­sion, can­cel­la­tion, or trans­fer » for the rea­sons sta­ted in Section 3.7.7.11. Those rea­sons include : if an ICANN adop­ted spe­ci­fi­ca­tion or poli­cy requires it or if a regis­trar or regis­try pro­ce­dure requires it « to cor­rect mis­takes by Registrar or the Registry Operator in regis­te­ring the name or for the reso­lu­tion of dis­putes concer­ning the Registered Name. » For example, the UDRP is an ICANN adop­ted poli­cy that spe­ci­fies that an admi­nis­tra­tive panel hea­ring a domain name dis­pute could order that a domain name regis­tra­tion be sus­pen­ded, trans­fer­red or can­cel­led, and the Registered Name Holder has to agree that this is a pos­si­bi­li­ty.
• The Registered Name Holder shall « indem­ni­fy and hold harm­less the Registry Operator and its direc­tors, offi­cers, employees, and agents from and against any and all claims, damages, lia­bi­li­ties, costs, and expenses (inclu­ding rea­so­nable legal fees and expenses) ari­sing out of or rela­ted to the Registered Name Holder’s domain name regis­tra­tion. » At its sim­plest, this means that if the Registry Operator (or its employees, etc.) for the regis­te­red name is sued because of the Registered Name Holder’s domain name regis­tra­tion, the Registered Name Holder will pay the Registry Operator for all fees and expenses in defen­ding against the suit as well as pay for any judg­ments or lia­bi­li­ties awar­ded. This « indem­ni­fi­ca­tion » is not sole­ly limi­ted to court cases.

Verification of contact infor­ma­tion
As des­cri­bed in more detail below, there are spe­ci­fi­ca­tions and poli­cies that may be crea­ted and that apply to the Registrars. Some of the spe­ci­fi­ca­tions or poli­cies may address a Registrar’s obli­ga­tion to veri­fy the contact infor­ma­tion sup­plied by the Registered Name Holder when the domain is first regis­te­red, as well as set­ting out requi­re­ments for per­io­dic re-veri­fi­ca­tion of contact infor­ma­tion.
Registrars are also requi­red to take « rea­so­nable steps » to veri­fy contact infor­ma­tion in the event any per­son noti­fies the Registrar that contact infor­ma­tion for a Registered Name is inac­cu­rate. The Registrar also has obli­ga­tions to act to cor­rect inac­cu­ra­cies in contact infor­ma­tion that the Registrar becomes aware of, even if the inac­cu­ra­cy was not repor­ted by anyone.
The Registrar must also main­tain pro­per contact infor­ma­tion for itself, inclu­ding a valid email and mai­ling address. This contact infor­ma­tion should be pos­ted on the Registrar’s web­site.
Reseller arran­ge­ments
The RAA imposes obli­ga­tions on Registrars wor­king with third-par­ty Resellers – per­sons or enti­ties that the Registrar contracts with to pro­vide Registrar Services. The RAA now requires Registrars to include spe­ci­fic items in the Registrar/Reseller Agreements, inclu­ding : pro­hi­bi­ting the Reseller from making repre­sen­ta­tions that it is accre­di­ted by ICANN ; requi­ring that all Reseller regis­tra­tion agree­ments include all pro­vi­sions that the Registrar is requi­red to include in its Registrar/Registered Name Holder Agreement ; requi­ring the post­ing of all links to all ICANN web­sites that the Registrar is obli­ga­ted to post ; and iden­ti­fi­ca­tion of the spon­so­ring regis­trar. The Reseller is also requi­red to make sure that that if a cus­to­mer is using a Reseller’s pri­va­cy or proxy regis­tra­tion ser­vice for a domain name regis­tra­tion, the Reseller does one of the fol­lo­wing three things : (1) depo­sit the iden­ti­ty and contact infor­ma­tion of the cus­to­mer with the Registrar ; (2) depo­sit the iden­ti­ty and contact infor­ma­tion in escrow ; or (3) posts a notice to the cus­to­mer that their contact infor­ma­tion is not being escro­wed.
The RAA also requires the Registrar to take com­pliance and enfor­ce­ment action against a Reseller vio­la­ting any of the requi­red pro­vi­sions.