Interim Report Review Inter-Registrar Domain Name Transfers ICANN DNSO Names Council Task Force on Transfers Public Discussion on Transfers of gTLD Names

Interim Report ReviewInterim Report Review

Inter-Registrar Inter-Registrar Domain Name Domain Name

TransfersTransfersICANN DNSO Names Council Task Force on Transfers

Public Discussion on Transfers of gTLD NamesPublic Discussion on Transfers of gTLD NamesTuesday October 28, 2002Tuesday October 28, 2002

OverviewOverview

• 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.

OverviewOverview

• 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.

Document StructureDocument Structure

• Five Major Sections– Principles– Provisions– Registrar Processes– Enforcement– Definitions

PrinciplesPrinciples

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.


• 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.


• 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.


• 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.


• 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.


• 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.


• 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?


• 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”.

ProvisionsProvisions

Definition;

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


• 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.


• 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.


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


• 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


• 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

Specific ProcessesSpecific 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.


• 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


• 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

EnforcementEnforcement

Definition;

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


• 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.


• 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.

More WorkMore 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.

DefinitionsDefinitions

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

Questions?Questions?

This proposal will be archived on the Web in MS-HTML format @

http://www.byte.org/irdx

Documents

Interim Report Review Inter-Registrar Domain Name Transfers ICANN DNSO Names Council Task Force on Transfers Public Discussion on Transfers of gTLD Names