1. Interim Report Review Inter-Registrar Domain Name Transfers ICANN DNSO Names Council Task Force on Transfers Public Discussion on Transfers of gTLD Names Tuesday October 28, 2002

2. Overview Document was initially tabled by Tucows to the Registrar Constituency (R’rarC) in mid- 2001 as a proposed best practice. After discussion within the constituency, Register.com & Tucows collaborated on a revised document that was accepted by the R’rarC as a formal position in late 2001.

3. Overview R’rarC tabled document with the Transfers Task Force in early 2002. The document has continually been revised by the Task Force since mid-2002 as the result of Constituency & GA input. –There have been over 50 draft versions since the first 2001 draft.

4. Document Structure Five Major Sections –Principles –Provisions –Registrar Processes –Enforcement –Definitions

5. Principles Definition; The underlying assumptions & requirements that guided the creation of the rest of the document. These are the keys to interpreting the document and implementing its recommendations.

6. Principles Registrars cannot place additional conditions or restrictions on transfers that aren’t covered in the recommendations. A Registrant’s right to transfer cannot be contracted away. Transfer processes should be secure and not subject to tampering.

7. Principles Registrars must keep records of transfer transactions and approvals. Registrars must conduct transfers in a way that promotes consumer confidence. New transfer policies should not mean new technologies or protocols.

8. Principles Transfer transactions should be auditable. Transfer transactions should take into account the global nature of the DNS. New processes or policies should not unduly burden any parties involved in a transfer. Transfer processes should be as automated as possible.

9. Principles Registrars and Registries should be free to implement the processes using whatever technology they choose except where interoperability requires standardization (ie – EPP/RRP) The Gaining Registrar is responsible for initiating and verifying the authenticity of a transfer request.

10. Principles Transfer processes should be as solid as possible to prevent gaming. Only the Registrant or Administrative Contact associated with a domain name may request and authorize a transfer.

11. Principles Transfer processes should be clear and easy to interact with for Registrants. Registrars must provide Registrants with authorization codes (where applicable) within 72 hours. RU Paying Attention?

12. Principles Registrars may not use the transfer process to hold a name “hostage” in the event that there is a dispute with the registrant over payment – other more appropriate mechanisms exist. –ie – “hold” instead of “lock” or “hold” instead of “nack”.

13. Provisions Definition; These are the global rules that all parties are bound to throughout the Inter- Registrar Domain Transfer processes.

14. Provisions The Gaining Registrar is solely responsible for validating the authenticity of a transfer request and the intent of the registrant. The Registrant and the Administrative Contact are the only parties that have the authority to approve a transfer.

15. Provisions A Standard Form of Authorization must be used to verify the intention of the Registrant. –This form can be “digital” or “analog” –A number of forms of identification are contemplated for “analog” and digital processes Ie – passport, electronic signature, etc.

16. Provisions The Gaining Registrar must store all documentation for later inspection by relevant parties –Registrants –Registrars –ICANN

17. Provisions Losing Registrars can only deny transfers in specific circumstances –Evidence of a fraudulent request –Pending UDRP action –Court order –Non-payment for a previous registration period –Express objection from the R’ant or Admin Contact

18. Provisions Specific “may not deny” circumstances are also included; –Non-payment for a future or pending registration period –Non-response of the R’ant or Admin Contact in the case of a secondary request for authenticity –Registration period time constraints –Generalized payment defaults between the registrar and one of their partners/resellers/affiliates

19. Specific Processes Definition; These are the specific processes that Registrars must implement (and Registries must facilitate) if they are to abide by the policy governing transfers.

20. Specific Processes One verification request sent to Registrants Capture of all relevant transaction data –Old whois –Time stamp of important events –Standard Form of Authorization Registrants continue to have full capability to approve or deny specific requests

21. Specific Processes Assumes that no request is valid on its face –Positive verification of R’ant’s intent is mandatory Legacy Registry (RRP) and New Registry (EPP) protocol “friendly” –Effectively deals with “authorization codes” that the new gTLD registries use to verify the identity of a requestor

22. Enforcement Definition; These are the specific mechanisms that third parties can use to ensure that the transfers process is abided by appropriately.

23. Enforcement Creates a new facility by which registrars could seek resolution and/or enforcement on specific “problem” transfers Seeks to provide Registrants with a predictable and efficient framework whereby problems with transfers can be solved.

24. Enforcement Allows for reversals Allows for appeals Does not pose a cost burden to the Registrant –The registrar that “loses” the proceeding pays for the full costs of the process. Allows registrar to choose between a third party “resolver” or the registry operator.

25. More Work Defining the FOA More specifics regarding the third party resolution process And other substantive issues from the public comment period… Working towards consensus …we need your help.

26. Definitions Definition; These are the precise statements of what certain words within the document actually mean. i.e. –“Administrative Contact” –“Losing Registrar” –“Consensus” (just kidding, no miracles ;) Goal: To provide a common frame of reference for discussion, implementation and ongoing execution

27. Questions? This proposal will be archived on the Web in MS-HTML format @ http://www.byte.org/irdx