Skip to main content
Resources

Frequently Asked Questions: Transfer Policy Updates (Change of Registrant)

General

Inter-Registrar Transfers

Change of Registrant

General

  1. Why was the Transfer Policy updated?

    The Transfer Policy was updated as part of ICANN's Policy Development Process.

    Specifically, the GNSO Council unanimously voted to approve the consensus policy recommendations of the IRTP Working Group C on 17 October 2012. The ICANN Board adopted the recommendations of the GNSO Council on 20 December 2012. ICANN worked in consultation with the GNSO Implementation Review Team, which was formed as directed by the GNSO Council to work with ICANN, to ensure that the resultant implementation fulfills the intentions of the approved policy recommendations.

  2. Where can I see the updates?

    A redline version of the Transfer Policy showing changes can be found here: https://www.icann.org/en/system/files/files/transfer-policy-redline-25may16-en.pdf [PDF, 552 KB]

Inter-Registrar Transfers

  1. Section I.A.2.2.3.1 states that the Form of Authorization (FOA) shall expire if "a period of sixty (60) days has passed since the FOA was issued by the Gaining Registrar, unless the Gaining Registrar allows automatic renewal of the FOA and the Registered Name Holder has expressly opted in to the automatic renewal." Does this mean the FOA shall automatically expire after a period of 60 days has passed?

    If the Gaining Registrar allows automatic renewal of the FOA, and the Registered Name Holder expressly opted in to the automatic renewal, the FOA will not automatically expire after a period of 60 days has passed.

  2. Can the registrar allow the Form of Authorization to expire after a period of less than 60 days, for example, after 20 days?

    Yes. The updated Transfer Policy does not explicitly prohibit the registrar from choosing a shorter period for the expiration of the Form of Authorization. Please note, though, that section I.A.1 of the Transfer Policy provides: "Registrars should make reasonable efforts to inform Registered Name Holders of, and provide access to, the published documentation of the specific transfer process employed by the Registrars."

  3. Section I.A.2.2.3.4 states that the Form of Authorization shall expire when the inter-registrar transfer is completed. When is an inter-registrar transfer completed?

    An inter-registrar transfer is completed when the domain name has been successfully transferred to the Gaining Registrar.

  4. Section I.A.2.2.4 states: "If the [Form of Authorization] expires pursuant to one of the aforementioned circumstances described in 2.2.3(a) – 2.2.3(c), prior to submitting the "transfer" request to the registry, in order to proceed with the transfer, the Gaining Registrar must reauthorize the transfer request via a new Form of Authorization." What does "prior to" mean in this context?

    "Prior to" means the domain name expires before the registrar submits the transfer request to the registry. For example, if a domain name expires on December 1, the registrar needs to submit the transfer request before December 1.

  5. If the Form of Authorization expires under any of the circumstances listed in section 1.A.2.2.3.1 – 1.A.2.2.3.4, must the Gaining Registrar issue a new Form of Authorization?

    Yes. The Gaining Registrar must issue a new Form of Authorization to reauthorize the transfer request.

  6. Section I.A.3.3 refers to a modified version of the Form of Authorization. Where can I find this modified version?

    Please see the modified Form of Authorization here: https://www.icann.org/resources/pages/foa-registrar-transfer-confirmation-2016-06-01-en.

  7. Section I.A.3.3 refers to "preapprove[d]" inter-registrar transfers. What is an example of a preapproved inter-registrar transfer?

    A Registered Name Holder may preapprove an inter-registrar transfer, for example, by putting its domain name(s) up for sale through a third party company, and explicitly pre-authorizing any inter-registrar transfers accompanying the sale of the domain name(s).

    In the event of any disagreement regarding the preapproval of the inter-registrar transfer, it is the registrar's responsibility to provide documentation of the Registered Name Holder's preapproval.

Change of Registrant

  1. What is considered a "material change," as referenced in Section II.A.1.1.3?

    Paragraph 1.1(c) defines Material Change to mean a nontypographical correction. Registrars have some flexibility to determine what a Material Change is. Examples of typographical corrections could include:

    1. Changing the Registrant Name field from oJhn Smith to John Smith.
    2. Changing the Registrant Name field from Jane Kgan to Jane Kang.
    3. Changing the Registrant Organization from Example, Icn. to Example, Inc.
    4. Changing the Registrant Organization from ExampleCorp. to Example Corp.

    For avoidance of doubt, nothing prevents the Registrar from treating any change to the Registrant Name or Registrant Organization field as a Material Change.

  2. What are examples of a "secure mechanism," as referenced in Sections II.C.1.1.2 and II.C.1.1.4?

    A non-exhaustive list of examples of secure mechanisms include:

    1. Sending an email requiring an affirmative response through a tool-based authentication method such as providing a unique code that must be returned in a manner designated by the Registrar.
    2. Calling – or sending a text message to – the Registered Name Holder and providing a unique code that must be returned in a manner designated by the Registrar.
    3. Calling the Registered Name Holder and requiring they provide a unique code that was sent to them via web, email or postal mail.

    Please note registrars should consider out-of-band authentication.

  3. Can the explicit consent requirement described in Sections II.C.1.1.2 and II.C.1.1.4 be merged with the email verification under the Whois Accuracy Program Specification?

    Yes. If the registrar obtains explicit consent in a way that satisfies the verification of email requirement under the Whois Accuracy Program Specification, i.e., "by sending an email requiring an affirmative response through a tool-based authentication method such as providing a unique code that must be returned in a manner designated by the Registrar," the registrar would not have to reverify the email address unless the registrar is in "possession of facts or knowledge of circumstances that suggest that the information is no longer valid."

  4. How can the registrar obtain explicit consent from a Prior Registrant, if the Prior Registrant's email is no longer valid?

    Footnote 1 of the Transfer Policy provides that: "The registrar may use additional contact information on file when obtaining confirmation from the Prior Registrant and is not limited to the publicly accessible Whois. The registrar is not limited to using a nonworking email address to obtain the explicit consent from the Prior Registrant."

  5. 14. Can a registrar allow the Prior Registrant to opt out of the 60-day inter-registrar transfer lock described in Section II.C.1.2 during the 60-day lock?

    The registrar has the option to opt out of the 60-day inter-registrar lock. The Transfer Policy explicitly states that "the Registrar may allow the Registered Name Holder to opt out of the 60-day inter-registrar transfer lock prior to any Change of Registrant request." Registrars may allow the Prior Registrant to opt out of the lock prior to the Change of Registrant request; however, registrars may not allow registrants to opt out of the 60-day inter-registrar transfer lock during the 60-day lock.

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."