Standardized IRDX Proposal

There are no accepted standard processes in place by which Registrars can undertake inter-registrar domain name transfers (IRDX). The lack of accepted standards have led to market confusion and a wide variety of Registrar implementations that may or may not suitably address the needs of the consumer and the contractual requirements Registrars operate under. This proposal attempts to document the processes and standards required to suitably engage undertake IRDX in compliance with the Verisign Registry/Registrar Agreements and the ICANN Accreditation Agreement. This document does not describe specific implementations or applications, but rather describes generic processes that can be accepted and implemented by Registrars. This document is a proposal draft and has not been ratified or endorsed by any part.

This document, while not an IETF draft, is offered under and subject to the terms of section 10 of RFC 2026.

Principles

Inter-registrar domain name transfers (IRDX) transactions MUST not be undertaken in conflict with existing ICANN policy.

IRDX processes MUST allow registrants to transfer their domain name registrations between registrars provided that the registration possesses certain minimum attributes.

IRDX processes MUST prevent parties not authorized by the registrant to complete an IRDX transaction.

IRDX transactions MUST be undertaken in a manner that engenders registrant confidence.

IRDX transactions SHOULD, wherever possible, be implemented using existing protocols and standards.

IRDX transactions MUST withstand reasonable audit before, during and after the transaction has occurred.

IRDX processes SHOULD take into account the global, local and multicultural

realities of the domain name registration market and registrants.

IRDX processes MUST NOT place undue burden on the registrant, registrar or registry.

IRDX processes SHOULD be automated. Nevertheless, specific implementations MUST remain at the discretion of the implementing party.

IRDX process implementation and administration MUST be the responsibility of the gaining registrar. IRDX process implementation and administration MUST NOT allow for undue influence or manipulation by the losing registrar or any other third party.

IRDX transactions MUST only be undertaken at the request of the registrant or a duly authorized agent of the registrant.

Registrants, or their duly authorized agents, MUST be provided the capability to verify their intention to complete an IRDX transaction as part of the IRDX process.

IRDX processes MUST be as clear and concise as possible in order to avoid confusing registrants or other stakeholders.

Gaining Registrar Processes

Gaining Registrar Processes Narrative

1) Entity Files Transfer Request – The entity in question may be any of the following: the actual registrant, someone authorized to act on his or her behalf, or any other unauthorized third party. This transfer request may be filed through virtually any means including telephone, email, web etc.

2) 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 authoritative representation of the Losing Registrar’s data.

3) Whois Data is invalid – This covers a number of conditions including invalid or out of date email addresses or other contact information

4) Whois Data is valid – Validity is solely determined when the Gaining Registrar can reasonably conclude that the data included in the losing registrar’s system is correct. (i.e. – email sent to the admin contact doesn’t bounce, telephone calls to the registrant go through).

5) Gaining Registrar attempts to contact Registrant or Administrative Contact for manual authorization – This can be undertaken, especially in automated environments, when the primary contact data is incorrect (ie – email address) but other data elements are correct (i.e. – phone number). The Gaining Registrar should use all means at their disposal to contact the Registrant or Administrative Contact. If no response is available, the transfer request must not be honored and must necessarily fail.

6) Registrant or Administrative Contact is provided with means of verification – this can take many forms including simplified web forms, paperwork or other mechanisms that cannot be reasonably intercepted, forged or otherwise unduly influenced by third parties. Let us call the documentation that verifies the transaction the authorization request.

7) Customer decides intent – This is a decision point during which the Registrant or Administrative Contact of record for the domain must determine whether or not they wish to undertake the transfer request.

8) Registrant/Administrative Contact denies authorization – self explanatory

9) No response is received from Registrant/Administrative Contact – self explanatory

10) Registrant/Administrative Contact verifies transfer request – self-explanatory however it must be noted that the form of verification must be undertaken in a manner that cannot be reasonably intercepted, forged or otherwise unduly influenced by third parties. Unfortunately, this discounts some of the more convenient mechanisms such as telephone or fax verifications except in limited circumstances where the Gaining Registrar is certain as of the validity of the verification (i.e. – the registrar is confirming a transfer on their own behalf, or has personal knowledge of the voice or handwriting of the registrant)

11) Transfer authorization record stored with transaction by Gaining Registrar – ICANN requires that authorization records must be stored for a period of time to ensure the validity of transactions on a historical basis. Data that should be stored as part of this process include;

- Name and email address of original requestor

- Registrant of record as declared by losing registrar Whois

- Administrative contact of record as declared by losing registrar Whois

- Time and date of original request

- Time and date of authorization/denial/expiry of transfer request by administrative contact of record

- Originating IP address of the individual undertaking the authorization of the request (where appropriate)

- Time and date filed with registry for processing (if appropriate)

12) Transfer request sent to verification queue for inspection – An inspection queue needs to be used to verify one last time as to the validity of the transfer request. See next description for full explanation.

13) Inspection – This can either be a manual inspection, automated inspection or a combination of both types. The purpose of this inspection is to ensure that obviously forged requests that have not been captured by previous processes are not forwarded to the registry for action. For instance, it is very unlikely that Network Solutions would undertake to transfer netsol.com to Tucows or vice versa. Manual inspections will catch this. It is recommended that registrars implement a manual and automated check. The automated portion should consist of a check against a blacklist of domains that should not be transferred in any case. Tucows maintains a blacklist of thousands of domains that must be manually inspected before the transfer request is filed with the registry.

14) Gaining Registrar does not approve transfer request – this can occur for any number of reasons including gut feel or suspicious transaction patterns.

15) Gaining Registrar approves transfer request – if the Gaining Registrar is fully satisfied with the apparent validity of the transaction, they can choose to promote the transfer request to the registry for processing.

16) Transfer request sent to registry – this is undertaking exclusively via the RRP/EPP between the Gaining Registrar and the relevant registry.

17) 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.

18) Losing Registrar minimum attribute check – Upon receipt of the transfer announcement sent by the registry, the Losing Registrar must undertake to ensure that the domain registration possesses the following attributes:

- It is not subject to situations described in the UDRP or other legal proceedings that superscede the registrants authority to transfer

- The registrant is not pending bankruptcy

- There is no dispute over the identity of the registrant

- The domain name has been registered for at least 60 days

19) Losing Registrar denies transfer – If the registration pending transfer does not possess the aforementioned attributes, the Losing Registrar may deny the transfer request.

20) Registry cancels transfer, notifies gaining registrar – self explanatory

21) Losing Registrar does nothing/acknowledges transfer – if the registration pending transfer possesses the aforementioned attributes, then the Losing Registrar must authorize the transfer request from the registry or do nothing.

22) Registry undertakes transfer and notifies Ggaining rRegistrar – self-explanatory.

23) Gaining Registrar notifies Registrant of successful transfer – self-explanatory. May be conducted by any number of means.

Losing Registrar Processes

Losing Registrar Processes Narrative

Note: This portion of the document is not as generic as it should be. This will be corrected in a future iteration.

1) Registry Transfer Notification – Registry sends out notification of pending transfer to Losing Registrar.

2) Losing Registrar Receives notification, makes note of “domain_name” – Losing Registrar determines which domain name is pending transfer away.

3) 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.

4) Notifies registrant of pending request to transfer to another registrar – Losing Registrar notifies registrant that their domain name is currently subject to a pending transfer away request.

5) Customer decides intent – Registrant reviews pending transfer request and determines whether or not they wish to continue with the transfer request, or whether or not the originating transfer request is even valid in the first place.

6) Do nothing/No Response – The Registrant chooses not to, or does not respond to the notification of pending transfer.

7) Verify transfer request –The Registrant explicitly approves the pending transfer request as being valid.

8) Deny transfer request – The Registrant explicitly denies the pending transfer request as being valid.

9) Transfer Fails – The Losing Registrar files a “n’ack” with the Registry.

10) Registry Undertakes transfer – The Registry allows the pending transfer request to continue as being a valid and approved transfer request.