Skip to content

Registrar’s Accreditation Agreement

Background: One of the new pro­vi­sions added to the 2009 RAA requires ICANN to devel­op in con­sul­ta­tion with reg­is­trars a web­page that iden­ti­fies avail­able reg­is­trant rights and respon­si­bil­i­ties. This pub­lished doc­u­ment is the result of ini­tial input from a joint work­ing group of the GNSO Council and the At-Large Advisory Committee and sub­se­quent con­sul­ta­tions with the reg­is­trars; and pro­vides a “plain lan­guage” sum­ma­ry of reg­is­trant rights and respon­si­bil­i­ties that cur­rent­ly exist under the 2009 RAA.

Introduction

This doc­u­ment pro­vides some “plain lan­guage” sum­ma­riza­tion of terms relat­ed to reg­is­trant rights and respon­si­bil­i­ties as set out in the reg­is­trar Accreditation Agreement (RAA), for post­ing on Registrar web­sites. While some of the terms includ­ed here do not specif­i­cal­ly refer to reg­is­trants, those terms are includ­ed because of the poten­tial import to under­stand­ing registrar/registrant rela­tions. This doc­u­ment also sum­ma­rizes reg­is­trant rights and respon­si­bil­i­ties that arise with­in ICANN Consensus Policies and spec­i­fi­ca­tions, as those poli­cies and spec­i­fi­ca­tions are incor­po­rat­ed into the RAA.’

The sum­ma­riza­tion of terms with­in this doc­u­ment do not over­ride or replace the terms set forth in the RAA or with­in those spec­i­fi­ca­tions or pol­i­cy.

Preamble

In order to reg­is­ter a domain name, a Registered Name Holder (also known as a Registrant) has to use the ser­vices of an ICANN-accred­it­ed Registrar. In order to become an ICANN-accred­it­ed Registrar, the Registrar must enter into a con­tract with ICANN, referred to as the Registrar Accreditation Agreement or the RAA. The RAA sets out var­i­ous rights and respon­si­bil­i­ties for Registrants, and Registrants have addi­tion­al rights and respon­si­bil­i­ties that are set forth in sep­a­rate ICANN poli­cies and spec­i­fi­ca­tions that the Registrars agree to fol­low.

The RAA and the relat­ed poli­cies are draft­ed in very spe­cif­ic, often legal ter­mi­nol­o­gy. In order to help Registrants bet­ter under­stand the rights and respon­si­bil­i­ties that come along with the reg­is­tra­tion of a domain name, these rights and respon­si­bil­i­ties are being sum­ma­rized and pre­sent­ed with­in a sin­gle doc­u­ment. The sum­maries pro­vid­ed here do not over­ride or replace the actu­al terms as writ­ten in the RAA or the relat­ed poli­cies and spec­i­fi­ca­tions.

RAA Terms of Interest

As the RAA is between ICANN and a Registrar, no one else — includ­ing 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 reg­is­trants with supe­ri­or access to any rel­e­vant TLD in com­par­i­son to oth­er Registrars.

Some of the Registrar oblig­a­tions are depen­dent upon Registered Name Holders ful­fill­ing cer­tain respon­si­bil­i­ties, par­tic­u­lar­ly as it relates to pay­ment of reg­is­tra­tion fees, sub­mis­sion of required data points to the Registrars, and sub­mis­sion of accu­rate data and time­ly updates to that required data. Registrars also have spe­cif­ic items on which they must pro­vide notice to Registered Name Holders, includ­ing noti­fi­ca­tions of the end of a reg­is­tra­tion term, use of Registered Name Holder’s Personal Data, and notices regard­ing escrow­ing of data for domain names reg­is­tered through pri­va­cy or proxy reg­is­tra­tion ser­vices, as well as the post­ing of fees for the recov­ery of reg­is­tered names.

Registrar Submission of Data to Registry Operators

For each rel­e­vant TLD, Registrars must sub­mit cer­tain data points relat­ing to each Registered Name with­in a TLD:

  • The name of the Registered Name being reg­is­tered (3.2.1.1);
  • The IP address­es of the pri­ma­ry name­serv­er and sec­ondary nameserver(s) for the Registered Name (3.2.1.2);
  • The cor­re­spond­ing names of those name­servers (3.2.1.3);
  • Unless auto­mat­i­cal­ly gen­er­at­ed by the reg­istry sys­tem, the iden­ti­ty of the Registrar (3.2.1.4);
  • Unless auto­mat­i­cal­ly gen­er­at­ed by the reg­istry sys­tem, the expi­ra­tion date of the reg­is­tra­tion (3.2.1.5); and
  • Any oth­er data the Registry Operator requires be sub­mit­ted to it (3.2.1.6).

Registered Name Holders are nor­mal­ly required to pro­vide the Registrar with infor­ma­tion relat­ing to name­servers (3.2.1.2 — 3), and there may be addi­tion­al data required 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 required to have an inter­ac­tive web page and port 43 Whois ser­vice that is avail­able to the pub­lic to query free of charge. The RAA spec­i­fies cer­tain data points that must be pro­vid­ed in response to a query:

  • The Registered Name (3.3.1.1);
  • The names of the pri­ma­ry name­serv­er and sec­ondary nameserver(s) for the Registered Name (3.3.1.2);
  • The iden­ti­ty of Registrar (which may be pro­vid­ed through Registrar’s web­site) (3.3.1.3);
  • The orig­i­nal cre­ation date of the reg­is­tra­tion (3.3.1.4);
  • The expi­ra­tion date of the reg­is­tra­tion (3.3.1.5);
  • The name and postal address of the Registered Name Holder (3.3.1.6)
  • The name, postal address, e‑mail address, voice tele­phone num­ber, and (where avail­able) fax num­ber of the tech­ni­cal con­tact for the Registered Name (3.3.1.7); and
  • The name, postal address, e‑mail address, voice tele­phone num­ber, and (where avail­able) fax num­ber of the admin­is­tra­tive con­tact for the Registered Name (3.3.1.8).

These data points are com­mon­ly referred to as Whois data. As dis­cussed below, Registered Name Holders are required to pro­vide a Registrar with time­ly updates to Whois data for a Registered Name. Upon receiv­ing the update, a Registrar is to “prompt­ly” update the Whois data. Registrars may con­tract out the main­te­nance of the pub­lic query func­tion.

The RAA allows Registrars to pro­vide bulk access to Whois data to third par­ties. When pro­vid­ing bulk access or access to the Whois data through the pub­lic query func­tion, the Registrar is required to restrict access for high vol­ume queries or oth­er restric­tions on uses of Whois data as spec­i­fied in the RAA, includ­ing mar­ket­ing activ­i­ties and mass solic­i­ta­tions. If a Registrar con­tracts the pub­lic func­tion query to an out­side par­ty, the Registrar must require any con­trac­tor pro­vid­ing the port 43 ser­vice to impose the same restric­tions on access to and use of the Whois data.

Communications with Registered Name Holders

Registrars are required to main­tain records of all com­mu­ni­ca­tions with Registered Name Holders, as well as records of infor­ma­tion pro­vid­ed to Registry Operators.

Escrow of Registered Name Holder Data

A Registrar is required to main­tain a data­base of all Whois data for all Registered Names reg­is­tered through the Registrar’s accred­i­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 avail­able) postal address, e‑mail address, voice tele­phone num­ber, and fax num­ber of the billing con­tact for each Registered Name.

In some instances, a reg­is­trant may choose to lim­it the amount of per­son­al infor­ma­tion that a Registrar makes avail­able in a Whois query. To do so, the name may be reg­is­tered through a pri­va­cy ser­vice (allow­ing a reg­is­trant to con­ceal per­son­al iden­ti­fy­ing infor­ma­tion and often replac­ing it with the infor­ma­tion of the pri­va­cy ser­vice). Customers may also choose to reg­is­ter names through a proxy ser­vice, where the proxy ser­vice is the Registered Name Holder, and the proxy ser­vice licens­es the use of the domain name to the cus­tomer. In that sit­u­a­tion, the proxy ser­vice, as the Registered Name Holder, has its infor­ma­tion list­ed for most or all required data points.

When a Registered Name is reg­is­tered through a pri­va­cy or proxy reg­is­tra­tion ser­vice, that affects the infor­ma­tion that is placed 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 postal address, e‑mail address, and voice tele­phone num­ber pro­vid­ed by the cus­tomer in con­nec­tion with each reg­is­tra­tion, even when a pri­va­cy or proxy reg­is­tra­tion is used; or (2) at the time that a cus­tomer elects to use a pri­va­cy or proxy reg­is­tra­tion ser­vice, dis­play a notice that the customer’s data is not being escrowed. When a customer’s data is not being escrowed, only the con­tact infor­ma­tion asso­ci­at­ed with the pri­va­cy or proxy reg­is­tra­tion ser­vice will be escrowed. If a customer’s data is not escrowed, and only the infor­ma­tion of the proxy or pri­va­cy ser­vice is main­tained in the data­base, in the event of Registrar or Registry fail­ure future notices may only be sent to the con­tact infor­ma­tion with­in the data­base.

Registrar Business Dealings with Registrants

The RAA impos­es many require­ments on a Registrar’s busi­ness deal­ings, includ­ing its deal­ings with Registered Name Holders.

A reg­is­trar may not acti­vate a Registered Name until it receives rea­son­able assur­ance from the Registered Name Holder that the reg­is­tra­tion fee will be paid.

The RAA sets forth actions the Registrar may take at the con­clu­sion of the reg­is­tra­tion peri­od if a Registered Name Holder has not pro­vid­ed con­sent to renew the reg­is­tra­tion, includ­ing the Registrar can­celling the reg­is­tra­tion at the end of the cur­rent reg­is­tra­tion term. If the Registered Name Holder did not con­sent to renew­al, the Registrar must make sure that a Registered Name is delet­ed from the Registry data­base with­in 45 days of the end of the reg­is­tra­tion term.

This right for the Registrar to can­cel the reg­is­tra­tion and the oblig­a­tion to the delete the domain name is not absolute. Section 3.7.5.1 of the RAA sets forth a list of poten­tial “exten­u­at­ing cir­cum­stances,” that, if exist, allows the Registrar to renew the domain name even with­out the con­sent of the Registered Name Holder. These cir­cum­stances include the Registered Name being sub­ject to a UDRP action, court order, bank­rupt­cy pro­ceed­ing, or billing dis­pute, among oth­er items. The Registrar must keep a record of rea­sons why the Registrar renewed a reg­is­tra­tion with­out the con­sent of a Registered Name Holder.

Registrars have to pro­vide each new reg­is­trant with notice of the Registrar’s dele­tion and auto-renew­al poli­cies. If the Registrar’s dele­tion pol­i­cy changes dur­ing the time of the reg­is­tra­tion agree­ment, the Registrar has to make efforts to inform the reg­is­trants of those pol­i­cy changes. Details of the dele­tion and auto-renew­al poli­cies have to be dis­played on any web­site the Registrar oper­ates for domain name reg­is­tra­tion and renew­al, and the Registrar should also state on those sites any fee that will be charged for the recov­ery of a domain name dur­ing the Redemption Grace Period (the 30 day peri­od of time dur­ing which the name is in “Pending Delete” sta­tus with the Registry).1

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 reg­is­tra­tion, the UDRP com­plainant has the right to renew (or restore, in the case of a dele­tion) the domain name. If the com­plainant renews or restores the name, the Registrar must place the name in a HOLD or LOCK sta­tus,2 and must mod­i­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 orig­i­nal domain name reg­is­trant to recov­er or renew the name in the event the UDRP com­plaint is ter­mi­nat­ed with­out deci­sion, or the UDRP com­plaint is decid­ed in favor of the orig­i­nal domain name reg­is­trant.

The Registrar/Registered Name Holder Agreement

Registrars are required to enter into elec­tron­ic or paper reg­is­tra­tion agree­ments with all Registered Name Holders. According to the RAA, the Registrar/Registered Name Holder Agreement must include — at min­i­mum — the fol­low­ing items (as stat­ed at Sections 3.7.7.1 — 12 of the RAA):

  • The Registered Name Holder must pro­vide “accu­rate and reli­able con­tact details” and must “prompt­ly cor­rect and update them” dur­ing the reg­is­tra­tion term. The details required are stat­ed in Section 3.7.7.1.: “the full name, postal address, e‑mail address, voice tele­phone num­ber, and fax num­ber if avail­able of the Registered Name Holder; name of autho­rized per­son for con­tact pur­pos­es in the case of an Registered Name Holder that is an orga­ni­za­tion, asso­ci­a­tion, or cor­po­ra­tion; and the data ele­ments list­ed in Subsections 3.3.1.2, 3.3.1.7 and 3.3.1.8.”
  • If a Registered Name Holder inten­tion­al­ly pro­vides inac­cu­rate or unre­li­able infor­ma­tion, inten­tion­al­ly fails to prompt­ly update the infor­ma­tion, or fails to respond over fif­teen (15) days to Registrar inquiries about the accu­ra­cy of the con­tact details, the Registered Name Holder will be in mate­r­i­al breach of the agree­ment and the reg­is­tra­tion may be can­celled.
  • Whoever is list­ed as the Registered Name Holder must pro­vide full con­tact infor­ma­tion, and is the Registered Name Holder of record. Sometimes a Registered Name Holder may reg­is­ter a domain name and then allow anoth­er per­son to use the domain name (such as a web­site design­er reg­is­ter­ing a domain name for a client). If this hap­pens, and the per­son actu­al­ly using the name did not enter into the Registrar/Registered Name Holder Agreement (referred to as a “third par­ty” in the RAA), the Registered Name Holder could be account­able for wrong­ful use of the domain name by the third par­ty. This will hap­pen if the Registered Name Holder is pro­vid­ed with “rea­son­able evi­dence of action­able harm” from the third party’s use of the domain name. In that sit­u­a­tion the Registered Name Holder will “accept lia­bil­i­ty for harm caused by wrong­ful use of the Registered Name,” unless the Registered Name Holder dis­clos­es the user’s iden­ti­ty and cur­rent con­tact infor­ma­tion.
  • The Registrar must pro­vide notice of how it intends to use data pro­vid­ed by the Registered Name Holder and who will received 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­vid­ed on a vol­un­tary basis. The Registered Name Holder must con­sent to all of these data pro­cess­ing 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­cussed above), the Registered Name Holder must con­firm that it (1) pro­vid­ed those third-par­ty indi­vid­u­als with the same data pro­cess­ing notices that the Registrar pro­vides, and (2) received the same con­sents from the third par­ty regard­ing the Registrar’s data pro­cess­ing terms.
  • A Registrar may only process the Registered Name Holder’s data as stat­ed in the data pro­cess­ing notices described above.
  • A Registrar has to agree that it will take rea­son­able pre­cau­tions to pro­tect the Registered Name Holder’s data from “loss, mis­use, unau­tho­rized access or dis­clo­sure, alter­ation, or destruc­tion.”
  • Registered Name Holders must rep­re­sent that: “to the best of the Registered Name Holder’s knowl­edge and belief, nei­ther the reg­is­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 rep­re­sent to the Registrar that the domain name is not being reg­is­tered for use in a way that would vio­late the legal rights of oth­ers. An exam­ple of this “infringe­ment” could be a reg­is­tra­tion of a domain name that vio­lates a trade­mark or copy­right held by some­one that is not the Registered Name Holder.3
  • If there is a dis­pute in con­nec­tion with the use of the reg­is­tered 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 locat­ed (often stat­ed 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­cif­ic mean­ing, but typ­i­cal­ly will be the loca­tion the Registered Name Holder pro­vides to the Registrar in the required Personal Data. Agreeing to juris­dic­tion means that the Registered Name Holder agrees that the courts in those loca­tions have the pow­er to decide these types of cas­es.4
  • The Registered Name Holder must agree that its reg­is­tra­tion is sub­ject to “sus­pen­sion, can­cel­la­tion, or trans­fer” for the rea­sons stat­ed in Section 3.7.7.11. Those rea­sons include: if an ICANN adopt­ed spec­i­fi­ca­tion or pol­i­cy requires it or if a reg­is­trar or reg­istry pro­ce­dure requires it “to cor­rect mis­takes by Registrar or the Registry Operator in reg­is­ter­ing the name or for the res­o­lu­tion of dis­putes con­cern­ing the Registered Name.” For exam­ple, the UDRP is an ICANN adopt­ed pol­i­cy that spec­i­fies that an admin­is­tra­tive pan­el hear­ing a domain name dis­pute could order that a domain name reg­is­tra­tion be sus­pend­ed, trans­ferred or can­celled, and the Registered Name Holder has to agree that this is a pos­si­bil­i­ty.
  • The Registered Name Holder shall “indem­ni­fy and hold harm­less the Registry Operator and its direc­tors, offi­cers, employ­ees, and agents from and against any and all claims, dam­ages, lia­bil­i­ties, costs, and expens­es (includ­ing rea­son­able legal fees and expens­es) aris­ing out of or relat­ed to the Registered Name Holder’s domain name reg­is­tra­tion.” At its sim­plest, this means that if the Registry Operator (or its employ­ees, etc.) for the reg­is­tered name is sued because of the Registered Name Holder’s domain name reg­is­tra­tion, the Registered Name Holder will pay the Registry Operator for all fees and expens­es in defend­ing against the suit as well as pay for any judg­ments or lia­bil­i­ties award­ed. This “indem­ni­fi­ca­tion” is not sole­ly lim­it­ed to court cas­es.

Verification of con­tact infor­ma­tion

As described in more detail below, there are spec­i­fi­ca­tions and poli­cies that may be cre­at­ed and that apply to the Registrars. Some of the spec­i­fi­ca­tions or poli­cies may address a Registrar’s oblig­a­tion to ver­i­fy the con­tact infor­ma­tion sup­plied by the Registered Name Holder when the domain is first reg­is­tered, as well as set­ting out require­ments for peri­od­ic re-ver­i­fi­ca­tion of con­tact infor­ma­tion.

Registrars are also required to take “rea­son­able steps” to ver­i­fy con­tact infor­ma­tion in the event any per­son noti­fies the Registrar that con­tact infor­ma­tion for a Registered Name is inac­cu­rate. The Registrar also has oblig­a­tions to act to cor­rect inac­cu­ra­cies in con­tact infor­ma­tion that the Registrar becomes aware of, even if the inac­cu­ra­cy was not report­ed by any­one.

The Registrar must also main­tain prop­er con­tact infor­ma­tion for itself, includ­ing a valid email and mail­ing address. This con­tact infor­ma­tion should be post­ed on the Registrar’s web­site.

Reseller arrange­ments

The RAA impos­es oblig­a­tions on Registrars work­ing with third-par­ty Resellers — per­sons or enti­ties that the Registrar con­tracts with to pro­vide Registrar Services. The RAA now requires Registrars to include spe­cif­ic items in the Registrar/Reseller Agreements, includ­ing: pro­hibit­ing the Reseller from mak­ing rep­re­sen­ta­tions that it is accred­it­ed by ICANN; requir­ing that all Reseller reg­is­tra­tion agree­ments include all pro­vi­sions that the Registrar is required to include in its Registrar/Registered Name Holder Agreement; requir­ing the post­ing of all links to all ICANN web­sites that the Registrar is oblig­at­ed to post; and iden­ti­fi­ca­tion of the spon­sor­ing reg­is­trar. The Reseller is also required to make sure that that if a cus­tomer is using a Reseller’s pri­va­cy or proxy reg­is­tra­tion ser­vice for a domain name reg­is­tra­tion, the Reseller does one of the fol­low­ing three things: (1) deposit the iden­ti­ty and con­tact infor­ma­tion of the cus­tomer with the Registrar; (2) deposit the iden­ti­ty and con­tact infor­ma­tion in escrow; or (3) posts a notice to the cus­tomer that their con­tact infor­ma­tion is not being escrowed.

The RAA also requires the Registrar to take com­pli­ance and enforce­ment action against a Reseller vio­lat­ing any of the required pro­vi­sions.

Other Policies/Specifications

The Restored Names Accuracy Policy (http://www.icann.org/en/registrars/rnap.htm) requires that when a reg­is­trar restores a name (from the redemp­tion grace peri­od) that had been delet­ed on the basis of sub­mis­sion of false con­tact data or non-response to reg­is­trar inquiries, the name must be placed on Registrar Hold sta­tus until the reg­is­trant has pro­vid­ed updat­ed and accu­rate Whois infor­ma­tion.

In addi­tion to the RAA require­ment that a Registered Name Holder rep­re­sent that to the best of its knowl­edge, the reg­is­tra­tion or use of the domain name does not infringe on the legal rights of oth­ers, the Uniform Domain Name Dispute Resolution Policy (“UDRP”) requires that same rep­re­sen­ta­tion to be made, as well as a rep­re­sen­ta­tion that the domain name is not being reg­is­tered for an unlaw­ful pur­pose, and will not be used in vio­la­tion of any applic­a­ble laws.

The UDRP also requires Registered Name Holders to sub­mit to manda­to­ry admin­is­tra­tive pro­ceed­ings to resolve dis­putes under the UDRP. These manda­to­ry admin­is­tra­tive pro­ceed­ings, as described in the UDRP, are dis­putes that are filed before one of the ICANN approved UDRP dis­pute res­o­lu­tion providers (list­ed at http://www.icann.org/en/dndr/udrp/approved-providers.htm) and fol­low­ing the uni­form Rules for UDRP admin­is­tra­tive pro­ceed­ings (set out at http://www.icann.org/en/dndr/udrp/uniform-rules.htm). The require­ment for sub­mis­sion to manda­to­ry admin­is­tra­tive pro­ceed­ings does not mean that Registered Name Holders can­not also have judi­cial pro­ceed­ings filed against them for the same or sim­i­lar con­duct. Similar to the juris­dic­tion­al require­ments set out in the RAA, the require­ment to sub­mit to a manda­to­ry admin­is­tra­tive pro­ceed­ing means that the Registered Name Holder can­not dis­pute the UDRP provider’s abil­i­ty to hear a dis­pute that is oth­er­wise prop­er­ly brought under the UDRP.

The Policy on Transfers of Registrations between Registrars pro­vides that Registered Name Holders have the right to trans­fer domain name reg­is­tra­tions among reg­is­trars. The trans­fer pol­i­cy impos­es time lim­its on when the Registrar must respond to a trans­fer request. The right to trans­fer is not absolute — there are ICANN and Registry poli­cies that may set lim­its on the trans­fer right, includ­ing: lim­i­ta­tions on when a domain name may be trans­ferred (mea­sured from dates of cre­ation or ear­li­er trans­fer); and the Registered Name Holder pro­vid­ing of required autho­riza­tion and doc­u­men­ta­tion for Registrar review. The Registrar of Record may only deny a trans­fer in the fol­low­ing instances:

  • Evidence of fraud
  • UDRP action
  • Court order by a court of com­pe­tent juris­dic­tion
  • Reasonable dis­pute over the iden­ti­ty of the Registered Name Holder or Administrative Contact
  • No pay­ment for pre­vi­ous reg­is­tra­tion peri­od (includ­ing cred­it card charge-backs) if the domain name is past its expi­ra­tion date or for pre­vi­ous or cur­rent reg­is­tra­tion peri­ods if the domain name has not yet expired. In all such cas­es, how­ev­er, the domain name must be put into “Registrar Hold” sta­tus by the Registrar of Record pri­or to the denial of trans­fer.
  • Express writ­ten objec­tion to the trans­fer from the Transfer Contact. (e.g. — email, fax, paper doc­u­ment or oth­er process­es by which the Transfer Contact has express­ly and vol­un­tar­i­ly object­ed through opt-in means)
  • A domain name was already in “lock sta­tus” pro­vid­ed that the Registrar pro­vides a read­i­ly acces­si­ble and rea­son­able means for the Registered Name Holder to remove the lock sta­tus.
  • The trans­fer was request­ed with­in 60 days of the cre­ation date as shown in the reg­istry Whois record for the domain name.
  • A domain name is with­in 60 days (or a less­er peri­od to be deter­mined) after being trans­ferred (apart from being trans­ferred back to the orig­i­nal Registrar in cas­es where both Registrars so agree and/or where a deci­sion in the dis­pute res­o­lu­tion process so directs).

1 A graph­ic rep­re­sen­ta­tion of the life cycle of a typ­i­cal gTLD Registered Name is locat­ed at http://www.icann.org/en/registrars/gtld-lifecycle.htm. This dia­gram may be use­ful to refer to for more infor­ma­tion on the post-expi­ra­tion sta­tus of domain names.

2 There are for­mal tech­ni­cal names for domain name sta­tus­es, aris­ing out of the com­mu­ni­ty-based Internet draft Request for Comments. The sta­tus­es required here are set by the Registrar. When a reg­is­tra­tion is in one of these sta­tus­es, the domain can­not be delet­ed and the reg­is­tra­tion can­not be mod­i­fied. The Registrar must alter the sta­tus in order for any mod­i­fi­ca­tion to occur.

3 There are many oth­er poten­tial ways to “infringe the legal rights” of oth­ers, and poten­tial Registered Name Holders are encour­aged to seek inde­pen­dent advice if they are con­cerned that the reg­is­tra­tion or use of a domain name may vio­late some­one else’s rights.

4 There could be oth­er juris­dic­tions that are able to decide a dis­pute about the use of a reg­is­tered name, but those addi­tion­al juris­dic­tions are not spec­i­fied in the RAA.