ICANN | Exhibit A to Final Report and Recommendations of the GNSO Council's Transfers Task Force

Final Report and Recommendations of the GNSO Council's Transfers Task Force
Exhibit A: Reference Application
30 November 2002
As updated 12 February 2003

Gaining Registrar Processes

Gaining Registrar Processes Narrative

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;

1. Physical: Form of Authorization signed by the Registrant or Administrative Contact of record. Such authorization must make explicit reference to the domain name(s) being transferred. A signed master FOA separate from an electronic communication with the domain names in question is also acceptable, so long as this master FOA is physically signed by both an authorized representative of the Gaining Registrar and the Registrant or Administrative Contact of record.

2. Electronic: A copy of the electronic communication sent to the Registrant or Administrative Contact of record, by the Gaining Registrar notifying, in reply to or confirming the initial domain name transfer request described in 5.f. The language of the electronic communication:

a. must make clear to the Registrant that its domain name is being transferred to the Gaining Registrar.

b. must be stored and saved with any applicable header information (date and time sent, sender, "to" addressee, etc.).

1. In case of an email authorization, the Gaining Registrar;

a. must retain a copy of the email to the Registrant or Administrative Contact of record, confirming the transfer, and;

b. must maintain log files reflecting all system transactions with respect to the above transfers, including

i. email addresses that communications were sent to in obtaining authorization of the transfer,

ii. the dates and times (mm/dd/yyyy hh:mm:ss) reflecting when;

1. the transfer was initially requested

2. the Gaining Registrar requested authorization

3. the FOA was obtained by the Gaining Registrar from the Registrant or Administrative Contact of record.

4. the Gaining Registrar filed the transfer of SLD Sponsorship request with the Registry,

5. a copy of the Whois information, as obtained from the Losing Registrars Whois database, for such domain name prior to the transfer for the domain name registration.

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.

Losing Registrar Processes

Losing Registrar Processes Narrative

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 webmaster@icann.org.