Final Report and Recommendations
of the GNSO Council's Transfers Task Force
Final Report and Recommendations of
the GNSO Council's Transfers Task Force
The following section is intended to act as a descriptive guide to the processes outlined in the previous.
a. Entity Files Transfer Request - The entity in question may be any of the following: the Registrant, the administrative contact, or someone authorized to act on the Registrant's behalf. This transfer request may be filed through virtually any means including telephone, email, web, etc. It is not mandatory at this point that the entity be verified as having the authority to initiate a change in SLD Sponsorship.
b. Gaining Registrar retrieves Whois record for domain from Losing Registrar and stores output - This could be accomplished through any Whois service as long as the output is an accurate representation of the Losing Registrar's data at the time of capture by the Gaining Registrar.
c. Whois Data is invalid - This covers a number of conditions including invalid or out of date email addresses or other contact information
d. Whois Data is valid - Validity is solely determined when the Gaining Registrar can reasonably conclude that the Whois data provided by the Losing Registrar is correct. (e.g. - email sent to the admin contact doesn't bounce).
e. Gaining Registrar attempts to contact the Registrant or Administrative Contact of record., for manual authorization - This can be undertaken, especially in automated environments, when the primary contact data is incorrect (e.g. - email address) but other data elements are correct (e.g. - phone number). The Gaining Registrar should use all means at their disposal to contact the Registrant or Administrative Contact of record. If no response is available, the transfer request must not be honored and must necessarily fail.
f. The Registrant is provided with means of verification - this may take many forms including simplified web forms or paperwork. The Gaining Registrar may choose to employ a means of verification not contemplated by this document as long as the means comply with this document, specifically the minimum standards of data acquisition and retention, in written or electronic form, as outlined in 5.k. The documentation that verifies the transaction is called the "Form of Authorization" (FOA). In all cases, the FOA must provide the Registrant with clear instructions for approving or denying the request for authorization, the identity of the Gaining Registrar (and other parties to the transaction - e.g. resellers) and a concise statement describing the impact of the Registrant's decision(s). This requirement is intended to ensure that the form of request employed by the Gaining Registrar is substantially administrative and informative in nature and clearly provided to the Registrant for the purpose of verifying the intent of the Registrant.
g. Customer decides intent - This is a decision point at which the Registrant or Administrative Contact of record must determine whether or not they wish to undertake the transfer request.
h. The Registrant or Administrative Contact of record denies authorization - Gaining Registrar does not continue the transaction.
i. No response is received from the Registrant or Administrative Contact of record - Gaining Registrar does not continue the transaction. No Response is received from the Registrant or Administrative Contact of record, - Gaining Registrar does not continue with the transaction.
j. The Registrant or Administrative Contact of record verifies transfer request – Acquisition of the FOA must be undertaken in a manner that can be documented and cannot be reasonably intercepted, forged or otherwise duly influenced by third parties.
k. Transfer authorization record stored with transaction by Gaining Registrar - In addition to the minimum data acquisition and retention requirements specified by ICANN and the Registry to ensure the validity of transactions from an audit perspective, at least one of the following forms of data must be acquired and retained by the Gaining Registrar in a form that facilitates the inspection rights of the Losing Registrar;
l. Transfer request sent to verification queue for inspection - An inspection queue should be used to re-verify the validity of the transfer request. See next description for full explanation.
m. Inspection (optional) - This may be a manual inspection, automated inspection or a combination of both. The purpose of this inspection is to ensure that obviously forged or suspect requests that have not been captured by previous processes are not forwarded to the Registry for action. It is recommended that Registrars implement both a manual and automated check. The automated portion should consist of a check against a blacklist of domains that must not be transferred.
n. Gaining Registrar does not approve transfer request - this can occur for any number of reasons, including suspicious transaction patterns.
o. Gaining Registrar approves transfer request - if the Gaining Registrar is satisfied with the apparent validity of the transaction, it may send the transfer request to the Registry for processing.
p. Transfer request sent to Registry - this is undertaken exclusively via the RRP or EPP between the Gaining Registrar and the Registry.
q. Registry sends transfer announcement to Losing Registrar - implementation details are typically at the sole discretion of the Registry in question. The Losing Registrar must adapt its systems and processes to the form and substance of this announcement in accordance with the minimum standards set forth in this document.
r. Losing Registrar minimum attribute check - Upon receipt of the transfer announcement sent by the Registry, the Losing Registrar may undertake to check that the domain registration is not subject to one or any of the conditions described in section 4f of this document:
s. Losing Registrar denies transfer - If the registration pending transfer possesses any, or any number of, the aforementioned attributes, the Losing Registrar may deny the transfer request in accordance with the relevant Registry Agreement.
t. Registry cancels transfer, notifies Gaining Registrar - self explanatory
u. Losing Registrar does nothing/acknowledges transfer - if the registration pending transfer does not possess the aforementioned attributes, then the Losing Registrar must authorize the transfer request.
v. Registry undertakes transfer and notifies Gaining Registrar - self-explanatory.
w. Gaining Registrar notifies the Registrant of successful transfer - self-explanatory. May be conducted by any number of means.
x. Transfer Fails – Self-explanatory.
The following section is intended to act as a guide to the processes outlined in the previous diagram.
a. Registry Transfer Notification - Registry sends out notification of pending transfer to Losing Registrar.
b. Losing Registrar Receives notification makes note of "domain_name" - Losing Registrar determines which domain name is pending transfer away.
c. Losing Registrar retrieves customer contact information from local database - Losing Registrar retrieves contact and customer details related to the domain pending transfer from its own records.
d. Notifies the Registrant of pending request to transfer to another Registrar - Losing Registrar notifies the Registrant that its domain name is currently subject to a pending transfer away request.
e. Customer decides intent – The Registrant reviews pending transfer request and determines whether or not he wishes to continue with the transfer request, or whether or not the originating transfer request is valid.
f. Do nothing/No Response - The Registrant chooses not to, or does not respond to the notification of pending transfer.
g. Verify transfer request - The Registrant explicitly approves the pending transfer request as being valid.
h. Deny transfer request - The Registrant explicitly denies the pending transfer request as being valid.
i. Transfer Fails - The Losing Registrar files a non-acknowledgement of transfer request ("n'ack") with the Registry in case of 7.h by the Registrant.
j. Registry Undertakes transfer - The Registry allows the pending transfer request to continue as being a valid and approved transfer request in case of step 7.f or 7.g by the Registrant.
Comments concerning the layout, construction and functionality of this site
should be sent to firstname.lastname@example.org.