interim report review inter-registrar domain name transfers
DESCRIPTION
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. Overview. - PowerPoint PPT PresentationTRANSCRIPT
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.
PrinciplesPrinciples
• 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.
PrinciplesPrinciples
• 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.
PrinciplesPrinciples
• 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.
PrinciplesPrinciples
• 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.
PrinciplesPrinciples
• 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.
PrinciplesPrinciples
• 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?
PrinciplesPrinciples
• 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.
ProvisionsProvisions
• 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.
ProvisionsProvisions
• 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.
ProvisionsProvisions
• The Gaining Registrar must store all documentation for later inspection by relevant parties– Registrants– Registrars– ICANN
ProvisionsProvisions
• 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
ProvisionsProvisions
• 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.
Specific ProcessesSpecific 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
Specific ProcessesSpecific 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
EnforcementEnforcement
Definition;
These are the specific mechanisms that third parties can use to ensure that the transfers process is abided by appropriately.
EnforcementEnforcement
• 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.
EnforcementEnforcement
• 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