Domain Name Supporting Organization
Interim Report of the Names Council's Transfer Task Force
|
|
|
The Transfer Task Force is posting its draft/interim report for comment. The report focuses on Inter-Registrar Domain Name Transfers and provides a draft set of processes and procedures, which are intended to improve the transfer process for both users and registrars.
The Task Force was formed after an extensive work effort within the Registrar Constituency itself to deal with problems where some registrars were declining transfers to a different registrar, after receiving a request from a registrant. After a discussion with user constituencies and within the Names Council, the Task Force was chartered to address transfer issues. As the Task Force began its work to understand the scope and underlying problems, it became clear that there was indeed a serious set of problems that were affecting both registrars and registrants negatively.
Various explanations were given for the denials of transfers, ranging from concerns about unauthorized transfers to expressions of concern about legal liability of proceeding without certain forms of proof, or possible loss of a registration during transfer. Registrars were upon occasion requesting new forms of identification from the registrant, such as a driver’s license or notarized statement. Registrants were beginning to complain about negative experiences when they sought to transfer a domain name from one registrar to another. A wide variety of complaints seem to plague what is supposed to be a competitive environment between registrars. Some registrants complained that they were being denied transfers because they were “too close” to their renewal date. Others told the Task Force that they were told that if they transferred their name, they stood a chance of losing it. One registrar expressed a concern that there was a great deal of “slamming” going on and they were denying transfers to prevent potential “slams”.
What became apparent is that there is so much variation and flexibility in procedures and processes that registrars can simply refuse to accept a registrant’s request for a transfer, with no penalty or cost, for this denial of service to a customer. Not all registrars were denying transfers, but the system of portability of registration is very inter-related, and when large registrars or large groups of mid sized registrars take particular actions, this has a ripple effect throughout the system.
As the Task Force examined the issues, it became apparent that it is difficult, if not impossible for self-interested parties to agree voluntarily on changes, which will enable a more balanced competitive marketplace in the registrar environment. As noted above, practices of a single large registrar will affect dozens of small registrars, while actions by 2-3 of the largest registrars means that choice is simply ‘on hold’. The work of the Task Force initially focused on the further identification of the problems/experiences; then further consideration of the possible approaches to solutions.
As the Task Force was underway, the ICANN board sent a new related work item to the Task Force, known as the Wait Listing Service (WLS) with a short time frame to undertake providing advice to the Board. This effort was not focused on developing consensus policy, but was a request from the Board for advice. Upon the conclusion of this request and the provision of the Task Force’s recommendations, the Task Force resumed its work on development of process and procedures to guide the transfer of domain names between competitive registrars. As part of its work on WLS, the Task Force developed two other related views which are noted later and which remain of concern to the Task Force – the importance of a standard domain name deletions period and process, and support for the redemption grace period.
The draft recommendations of the Task Force are contained in an extensive insert into this Interim Report of the Transfer Task Force, in Section III, DRAFT CONCLUSIONS. The insert is entitled Inter-Registrar Domain Name Transfers: Principles and Processes for Gaining and Losing Registrars.
Also incorporated in this section are the supporting arguments, which will be moved to Section VIII, in the Final Report. The DRAFT CONCLUSIONS provide detailed processes, which the Task Force recommends, for all gTLD registrars. Extensive description including flowcharts to clarify the recommended processes, are provided in the DRAFT RECOMMENDATIONS.
The Task Force very early on considered a variety of approaches, and it soon became apparent that a standardized approach which could be used for the majority of registrants, based on a kind of “code, generated by the registrar at the time of registration, and tied to the registrant for that particular domain name’s registration, would provide a framework to manage effectively and consistently, those registrations where such codes [referred in the document as Auth-Info codes] were available. Recognizing that in some instances, such codes could be withheld, or delayed in their release for a variety of reasons, the Task Force also provides guidance regarding assuring that these codes are provided, and how problems in this area maybe handled. Secondly, recognizing that in some instances, registrars may choose, for a variety of reasons, not to provide such codes, or may delay in instituting the availability of such codes, the Task Force recommends a system which provides guidance on what documentation, or which individual can be considered to be “authoritative” in requesting a transfer.
The document asks for your feedback on all these recommendations, and seeks to hear from all interested parties, constituencies, and the General Assembly. In particular, the Task Force needs to hear from those who do not agree with the recommendations. If there are not opposing comments, the Task Force will note this lack of opposition in the final report.
We have tried to take input along the way, and have had some participation and feedback already. We have benefited from the participation of several individuals who have had personal experiences with transfers and have been willing to discuss these with us, so that we can better understand the impact upon registrants. What is clear to us is that we need, and count on registrant/user feedback and comment during the comment period. We have also benefited from the participation of the Registrar Constituency, both within the Task Force and by providing, on an ongoing basis, feedback regarding their views and concerns. And, from the ongoing contribution of all members of the Task Force, who spent numerous hours in seeking to understand, document, and cooperate to develop a process which can bring more certainty into a critical process and which addresses the needs and interests of the supplier of the registration process, and the user of that process in a fair, open, and cost effective manner, and which provides an appeals or problem resolution process with those same characteristics.
An underlying theme in the recommended process is the dependency on accurate and current WHOIS contact information. The Task Force also identified the need for a standard deletions process/period, adhered to by all registrars. This was part of their earlier recommendation on WLS, as well as a standard redemption period for deleting names. Although this Task Force will not directly participate in the Deletions Task Force development of a recommendation, we wish to note that our earlier recommendations and our discussions have assumed that such a standard deletions process would be developed, and implemented. The same thing is true for accurate contact information. This Task Force is dependent upon the recommendations of the WHOIS Task Force in this instance.
We offer our Interim Report for public comment period, which we propose to hold open for a period of 3 and one half weeks, through the Shanghai ICANN meeting. During the ICANN meeting, a session is planned where the Task Force will participate to present our recommendations, and to take part in further dialogue regarding transfers. The recommendations will be a topic of discussion at the Names Council. Comments will then be taken into account, and a final recommendation presented to the Names Council for final review and recommendation to the Board.
Stability and certainty in the key functions of the process of obtaining and using a domain name are important to the users themselves, and to those who come to rely upon that web site… Obtaining the domain name itself is a critical, but small part of the process of being on the Net. In fact, the domain name itself starts out being a very small part of the financial investment needed to put up a web site. But once the web site is in place, and relied upon as a resource, its stable and reliable operations are critical to the domain name holder, and to many others who use the site. And, being able to make a transfer from one registrar to another, based on registrant choice, whatever the reason, is a basic and fundamental “building block” in the system. Achieving an effective, secure, reliable set of processes, which support such transfers by the registrants, must be a shared goal.
The Task Force welcomes your comments and insights. We understand that our Interim Report will not answer all your questions, and in fact much of the work we will be doing over the next four weeks will be to complete the required documentation to support the policy recommendations of the Task Force. Again, we urge those who support, and those who do not agree to provide comments.
For registrants, we understand that the Report may appear rather “dense”. We have made it a practice to host open conference calls to support dialogue. Based on the comments we receive, we are open to such a further dialogue via conference call with interested parties.
The Task Force looks forward to your comments and questions.
Submitted by Marilyn S.Cade
Chair, Transfer Task Force
October 15, 2002
The terms of reference are provided by a link to the archives.
The following insert is the result of an extensive work effort chaired by Ross Rader, and involving representatives from several constituencies. The names of the Task Force members, and the Drafting Team members are provided in an Appendix.
Status: Committee Final
Inter-Registrar Domain Name Transfers:
Principles and Processes for Gaining and Losing Registrars
Transfer_Task_Force_Interim_Report.doc
Inter-Registrar Domain Name Transfers:
Principles and Processes for Gaining
and Losing Registrars
Table of Contents
Gaining Registrar Processes Narrative
Optional Losing Registrar Processes
Exhibit B of the Registrar-Registry Agreement ("RRA") provides a general framework to govern the transfer of SLD Sponsorship between Registrars. In the interest of fostering an environment that promotes consumer confidence and facilitates such transfers between ICANN accredited Registrars, the ICANN DNSO Names Council Task Force on Transfers proposes that ICANN adopt the following recommendations which when expressed as binding policy between registrars and registries, outlines a set of standard processes by which;
Gaining Registrars would obtain reliable authorization, or evidence of reliable authorization such as Authorization Information (AuthInfo) Codes in the case of EPP based registries, from appropriate authorities of transfer requests, and
Losing Registrars would authorize the transfer of such domain names in the absence of confirmation to the Losing Registrar by the Registrant or Administrative Contact of record.
Inter-registrar domain name transfers become transactions predicated on trust and an assumed lack of malfeasance on behalf of any party to the transaction.
This document allows for variations in the implementation of these standards, as long as the prescribed minimum standards are complied with. This document furthermore provides for processes for a Losing Registrar to verify the Gaining Registrars' compliance with these minimum standards.
This document, while not an IETF draft, is offered in accordance with, and subject to, the terms of section 10 of RFC 2026.
The drafting committee recommends that the TF consider the creation of the “Standard Form of Authorization” separately from this document. [Chair’s Note: The Task Force has done some preliminary thinking of how best to address this issue and will make a recommendation in the final report.]
General Principles
General Principles. These general principles outline not only the basic philosophical points that were taken into account during the drafting of this document, but also those principles that are required for a registrar, registry or registrant to effectively implement or initiate the processes described in this document.
Inter-registrar domain name transfers (IRDX) transactions MUST NOT be undertaken in conflict with ICANN or Registry contracts. If a conflict occurs, ICANN or Registry contracts MUST take precedent. Registrars (and their agents) MUST NOT place additional restrictions upon a Registrant in the form of a service contract in a manner contrary to ICANN or Registry policy and/or contract with respect to IRDX transactions.
IRDX processes MUST allow Registrants to transfer their domain name registrations between registrars provided that the Gaining Registrar's transfer process follows minimum standards and such transfer is not prohibited by ICANN or registry policies.
IRDX processes MUST prevent parties not authorized by the Registrant, pursuant to Registry and ICANN contracts, from completing an IRDX transaction.
IRDX processes MUST require Gaining Registrars to maintain reliable evidence of express authorization by the Registrant or Administrative Contact of record..
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 inspection before, during and after the transaction has occurred.
IRDX processes MUST take into account the legal, linguistic and cultural differences of the domain name registration market, registrars, and Registrants.
IRDX processes MUST NOT place undue burden on the Registrant, registrar or registry.
IRDX processes SHOULD be automated.
Specific implementations of IRDX processes MUST remain at the discretion of the implementing party.
IRDX process implementation and administration MUST be the responsibility of the Gaining Registrar. This is the underlying statement of default action and rule.
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 Administrative Contact of record.
Registrant or Administrative Contact of record, 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.
IRDX processes MUST be subject to post-transfer verification by the Losing and Gaining Registrar and other relevant third parties such as ICANN, the Registry Operator or a third party Dispute Resolution Panel.
Registrars MUST provide the Registrant with the Registrant’s unique “AuthInfo Code” within 72 hours of the Registrant’s initial request. Registrar may not employ any mechanism for a Registrant to obtain its AuthInfo Code that is more restrictive than what it requires from a Registrant to change any aspect of its contact or nameserver information.
In the event of dispute(s) over payment, the Losing Registrar MUST NOT employ transfer processes as a mechanism to secure payment for services from a Registrant. This includes “N’ACK” of transfer requests from the registry and/or non-release of “AuthInfo Codes” to the registrant.
The Losing Registrar MAY use the EPP or RRP command set equivalent of “Registrar Hold” prior to receiving a transfer notification from the Registry as a mechanism to secure payment from a Registrant in the event of non-payment. The Losing Registrar MAY NOT use the EPP or RRP command set equivalent of “Registrar Lock” for this same purpose.
In order that the IRDX policy may be successfully implemented by registrars and registries, the following conditions must be positively met;
Registrars must provide and maintain an email address for use by all other registrars and registries where communications concerning the IRDX process can be sent and dealt with by the receiving Registrar
The Gaining Registrar is solely responsible for validating registrant requests to transfer domain names between registrars
The Administrative Contact and the Registrant, as outlined in the Losing Registrar’s publicly accessible Whois service are the only parties that have the authority to approve or deny a transfer request to the Gaining Registrar. In all cases, the wishes of the Registrant supercede those of the Administrative Contact.
The Gaining Registrar must use the Standard Form of Authorization to seek the approval of the Registrant or Administrative Contact.
In the event that the Gaining Registrar must rely on a physical process to obtain this authorization, a paper copy of the Standard Form of Authorization will suffice insofar as it has been signed by the Registrant or Administrative Contact and is accompanied by a physical copy of the Losing Registrar’s Whois output for the domain name in question.
If the gaining registrar relies on a physical
authorization
process, they assume the burden of obtaining
reliable evidence of identity
of the Registrant or
Administrative Contact and that the entity making the
request
is indeed authorized to do so.
Recommended forms of identity include:
·
Notarized statement
· Valid Drivers license
·
Passport
· Article of Incorporation
·
Military ID
· State/Government issued ID
·
Birth Certificate
In the event of an electronic authorization
process, recommended forms of identity would include;
·
electronic signature in conformance with national legislation,
for instance, the United States e-Sign Act
· email
address matching Registrant or Administrative Contact email
address found in authoritative Whois database.
Copies of this reliable evidence of identity
must be kept with the Standard
Form of Authorization described
in section 3.d.i.The Gaining Registrar must retain, and produce
pursuant to a reasonable request by a Losing Registrar, a written
or electronic copy of Standard Form of Authorization. The Losing
Registrar retains the right to inspect this documentation at all
times.
In instances where the Losing Registrar has requested copies of the Standard Form of Authorization, the Gaining Registrar must fulfill the Losing Registrar’s request (including providing the attendant supporting documentation) within 3 business days receiving of the request. Failure to provide this documentation within the time period specific is grounds for reversal by the Registry Operator or Dispute Resolution Panel in the event that a transfer complaint is filed in accordance with section 8 of this document
A Losing Registrar may deny a transfer request only in the following instances;
Evidence of fraud
UDRP action
Court order
Dispute over the identity of the Registrant or Administrative Contact
No payment for previous registration period (including credit card charge-backs) if the domain name is past its expiration date or for previous or current registration periods if the domain name has not yet expired; in all such cases, the domain name must be put into “Registrar Hold” status prior the denial of transfer.
Express objection from the Registrant or Administrative contact
Instances when the Losing Registrar may not deny a transfer include, but are not limited to;
Nonpayment for a pending or future registration period
No response from the Registrant or Administrative contact unless the Losing Registrar shows evidence of Express Objection from the Registrant or Administrative Contact as described in section 3.e.vi
Domain name in Registrar Lock Status
Domain name registration period time constraints other than during the first 60 days of initial registration.
General payment defaults between registrar and business partners / affiliates in cases where the registrant for the domain in question has paid for the registration.
The Gaining Registrar must retain, and produce pursuant to a reasonable request by a Losing Registrar, a written or electronic copy of the Standard Form of Authorization by the Registered Name holder or an individual who has the apparent authority to legally bind the Registered Name holder. The Losing Registrar retains the right to verify the Registered Name holder's intent to transfer its domain name to the Gaining Registrar.
The verification of intent undertaken by the Losing Registrar must be undertaken in a manner consistent with the standards set forth in 5.f of the Gaining Registrars Process Narrative of this document, which describes the attributes of the FOA. Specifically, the form of the request employed by the Losing Registrar must provide the Registered Name holder with clear instructions for approving or denying the request for authorization and a concise declaration describing the impact of the Registered Name holder's decision(s).
This requirement is not intended to preclude the Losing Registrar from marketing to its existing customers through separate communications. This requirement is intended to ensure that the form of the request employed by the Losing Registrar is substantially administrative and informative in nature and clearly provided to the Registered Name holder for the purpose of verifying the intent of the Registered Name holder.
Diagram 4.0
The following section is intended to act as a descriptive guide to the processes outlined in Diagram 4.0.
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.
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.
Whois Data is invalid - This covers a number of conditions including invalid or out of date email addresses or other contact information
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).
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.
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.
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.
The Registrant or Administrative Contact of record denies authorization - Gaining Registrar does not continue the transaction.
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.
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.
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;
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.
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;
must make clear to the Registrant that its domain name is being transferred to the Gaining Registrar.
must be stored and saved with any applicable header information (date and time sent, sender, "to" addressee, etc.).
In case of an email authorization, the Gaining Registrar;
must retain a copy of the email to the Registrant or Administrative Contact of record, confirming the transfer, and;
must maintain log files reflecting all system transactions with respect to the above transfers, including
email addresses that communications were sent to in obtaining authorization of the transfer,
the transfer was initially requested
the Gaining Registrar requested authorization
the FOA was obtained by the Gaining Registrar from the Registrant or Administrative Contact of record.
the Gaining Registrar filed the transfer of SLD Sponsorship request with the Registry,
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.
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.
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.
Gaining Registrar does not approve transfer request - this can occur for any number of reasons, including suspicious transaction patterns.
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.
Transfer request sent to registry - this is undertaken exclusively via the RRP or EPP between the Gaining Registrar and the Registry.
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.
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:
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.
Registry cancels transfer, notifies Gaining Registrar - self explanatory
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, unless the Gaining Registrar did not follow the minimum procedures described herein. In such case, the losing registrar may deny the transfer according to the processes described in this document.
Registry undertakes transfer and notifies Gaining Registrar - self-explanatory.
Gaining Registrar notifies the Registrant of successful transfer - self-explanatory. May be conducted by any number of means.
Transfer Fails – Self-explanatory.
Diagram 6.0
The following section is intended to act as a guide to the processes outlined in Diagram 6.0.
Registry Transfer Notification - Registry sends out notification of pending transfer to Losing Registrar.
Losing Registrar Receives notification makes note of "domain name" - Losing Registrar determines which domain name is pending transfer away.
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.
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.
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.
Do nothing/No Response - The Registrant chooses not to, or does not respond to the notification of pending transfer.
Verify transfer request - The Registrant explicitly approves the pending transfer request as being valid.
Deny transfer request - The Registrant explicitly denies the pending transfer request as being valid.
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.
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.
This section attempts to create a process by which registrars could seek enforcement on specific issues directly with the appropriate registry operator and, if necessary, escalate to a “Dispute Resolution Panel” as a final measure in the case of disputes that were not clear violations of policy. Registrars are responsible for initiating these enforcement and resolution processes.
There are three levels to the dispute resolution process
Request for enforcement
A registrar may choose to file their dispute directly with the relevant Registry Operator. This is the first level of resolution, but may be appealed to the Dispute Resolution Panel.
Appeal to Third Party resolution
A registrar dissatisfied with the findings of the Registry Operator may appeal the finding to the Dispute Resolution Panel.
Third party resolution
A registrar may choose to file their dispute directly with the Third Party Resolution panel, in which case, they forfeit their right to an appeal and the decision of the panel is binding.
The Registry Operator is responsible for resolving disputes that fall under section 9.a.i above.
Disputes that fall under section 9.a.i are those that arise under the Registry/Registrar contracts.
Request for Enforcement Process
Registrar files a Request for Enforcement with the applicable Registry Operator
Registry Operator would request all applicable documentation not already received from the Gaining and Losing Registrars within three (3) registry business days of receipt of the request.
Registry would review the data in the documentation and compare such data with that contained within the authoritative Whois database. In all cases, the authoritative Whois database is that contained in the Registry Operator’s Whois database. If the Registry Operator Whois does not provide enough information to make an informed finding, the Registry Operator will rely on the data contained in the Losing Registrar’s Whois database.
If the data does not match, the Registry Operator should contact each Registrar and require additional documentation
If the gaining registrar cannot provide a complete FOA, where such data matches that contained within the authoritative Whois database, then the Registry Operator shall find that the transfer should be reversed.
If the losing registrar cannot provide evidence that on its face demonstrated any of the factors contained in Section 3(e) above, and the gaining registrar provides to the Registry a complete FOA, which appears accurate on its face, then the transfer should be approved.
If the data provided by neither registrar appears to be either valid or conclusive on its face, then the registry shall issue a finding of “no decision.” And refers the issue to the Dispute Resolution Panel.
The request for enforcement process must complete within 14 business days of receipt of the request for enforcement by the registry.
Fees. The gaining and losing registrars recognize that providing this dispute resolution service may result in extra costs to the Registry Operator. As such, the issue of appropriate fees (if any) that a Registry Operator may charge, and who is responsible for such fees (if any), shall be determined by ICANN in consultation with the gTLD Registries and Registrars. In the event that any fees are assessed for providing this service, the party that loses such dispute shall be responsible for covering the entire amount of fees. Such fees shall not be passed on to the legitimate registrant.
Appeal Process
Refer to dispute resolution panel/provider
Third Party Resolution
Refer to dispute resolution panel/provider
Either Registrar (Gaining or Losing) may commence a Dispute Resolution Proceeding against the other Registrar, whose specific rules or procedures should be determined by a drafting committee of the Transfer Task Force after a period of public notice and comment. The drafting committee shall keep the following principles in mind:
The DRP proceeding shall be conducted by an independent neutral third party that is neither associated or affiliated with either the Losing or Gaining Registrar or the Registry Operator under which the disputed domain name is registered;
Under the DRP policy, the filing Registrar (the “Complainant”) shall pay the initial filing fee (which shall be returned to the Complainant in the event that its challenge is successful).
The Registry Operator, under which the disputed domain name is registered, shall provide whatever data is needed by the Dispute Resolution Panel.
The sole purpose of the Dispute Resolution Panel should be to make a determination as to whether the complainants filing has merit as by current Transfer policy and determine what resolution to the complaint will appropriately redress the problem as described in the initial filing. The DRP may not deliberate disputes that fall outside of this mandate.
In the event that the complaint is found to
be without merit the
filing Registrar shall have forfeited its
initial filing fee. In addition,
if the Dispute
Resolution Panel makes as specific determination that that
the
complaint was either frivolous or brought for the purposes of
harassing
the "defendant", the Dispute
Resolution Panel may impose sanctions or
penalties on the
filing Registrar as long as such fees are not explicitly and
specifically recharged to the legitimate Registrant involved in
the dispute. Any Such sanctions or penalties that may be
imposed by the Dispute Resolution Panel shall be determined in
advance by the Task force an ICANN staff-led drafting committee
after public notice and comment.
In the event that the complaint is found to have merit, the Dispute Resolution Panel shall find in favor of the filing Registrar and shall require the following:
The transfer of the domain name subject to the complaint may be returned to the appropriate Registrar at no cost to the prevailing Registrar or Registrant.
The defending Registrar shall reimburse the complaining Registrar for the initial filing fee. Failure to pay this fee to the complaining Registrar may result in the loss of accreditation by ICANN.
If the Dispute Resolution Panel makes as specific determination that that the defending Registrar had no good faith basis for initiating the transfer, the Dispute Resolution Panel may impose additional sanctions or penalties on the defending Registrar as long as such fees are not explicitly and specifically recharged to the legitimate Registrant involved in the dispute. Such sanctions or penalties that may be imposed by the Dispute Resolution Panel shall be determined by the TF drafting committee after public notice and comment.
AuthInfo: See Authorization Information Codes
Authorization Information Codes: Authorization information is associated with domain objects to facilitate transfer operations This information is stored as a series of codes and assigned when a domain object is created. The codes can be updated by both registrars and customers. Password-based authorization is typical, but other mechanisms are allowed for by the protocols that support the transfers.
Contact: Contacts are individuals or entities associated with domain name records. Typically, third parties with specific inquiries or concerns will use contact records to determine who should act upon specific issues related to a domain name record. There are typically three of these contact types associated with a domain name record, the Administrative contact, the Billing contact and the Technical contact.
Contact, Administrative: The administrative contact is an individual, role or organization authorized to interact with the registry or registrar on behalf of the Domain Holder. The administrative contact should be able to answer non-technical questions about the domain name's registration and the Domain Holder. In all cases, the Administrative Contact is viewed as the authoritative point of contact for the domain name, second only to the Domain Holder.
Contact, Billing: The billing contact is the individual, role or organization designated to receive the invoice for domain name registration and re-registration fees.
Contact, Technical: The technical contact is the individual, role or organization who is responsible for the technical operations of the delegated zone. This contact likely maintains the domain name server(s) for the domain. The technical contact should be able to answer technical questions about the domain name, the delegated zone and work with technically oriented people in other zones to solve technical problems that affect the domain name and/or zone.
DNS: See “Domain Name System”.
Domain Holder: The individual or organization that registers a specific domain name. This individual or organization holds the right to use that specific domain name for a specified period of time, provided certain conditions are met and the registration fees are paid. This person or organization is the "legal entity" bound by the terms of the relevant service agreement with the registry operator for the TLD in question.
Domain Name System: The domain name system is a distributed database arranged hierarchically. Its purpose is to provide a layer of abstraction between other Internet services (web, email, etc.) and the numeric addresses (IP addresses) used to uniquely identify any given machine on the Internet.
EPP: See “Extensible Provisioning Protocol”
Exclusive Registration System: A domain name registration system in which registry services are limited to a single registrar. Exclusive Registration Systems may be either loosely coupled (in which case the separation between Registry and Registrar systems is readily evident), or tightly coupled (in which case the separation between registry and registrar systems is obscure).
Extensible Provisioning Protocol: an IETF standard for Internet domain name registration between domain name registrars and domain name registries. This protocol provides a means of interaction between a registrar's applications and registry applications. Based on a standard XML schema.
FOA: See “Form of Authorization”
Form of Authorization: [ FOA ] When a Gaining Registrar is in the process of executing a domain name transfer it must provide the registered domain name holder with a means of verification. The documentation that verifies the transaction is called the "Form of Authorization" (FOA).
GTLD: See “Top Level Domain, Generic”.
Glue Record: A Glue Record is an A record that is created as part of a delegation.
ICANN: Internet Corporation for Assigned Names and Numbers. A non-profit organization founded to assume responsibility for IP address space assignment, protocol parameter assignment, domain name system management and root server system management.
IANA: Internet Assigned Numbers Authority. The prior organization that was tasked with responsibility for IP address space assignment, protocol parameter assignment, domain name system management and root server system management. Now limited to performing the technical delegation of TLDs under ICANN.
InterNIC: The InterNIC, a registered service mark of the U.S. Department of Commerce, is a concept for an integrated network information center that was developed by several companies, including Network Solutions, in cooperation with the U.S. Government. Until recently, the term InterNIC is being used in conjunction with a neutral, stand alone web page (located at http://www.internic.net) that has been established to provide the public with information regarding Internet domain name registration. ICANN has recently undertaken an agreement with the United States Department of Commerce to undertake operation of the effort. The InterNIC was originally created by NSF to provide specific Internet services; directory & database services (by AT&T), registration services (by Network Solutions) and information services (by General Atomics/CERFnet).
Inter-registrar Domain Name Transfers: [ IRDX ] In a domain name transfer, the registrant changes the service that provides the front-end domain name service. The service provided to registrant requires that the Gaining Registrar make a formal request to the Losing Registrar to make the Gaining Registrar the official service providing domain name service for that name. The request that passes between the registrars is the Inter-registrar Domain Name Transfer.
IRDX: See inter-registrar domain name transfers.
ISO-3166-1: A document maintained by the International Standards Organization that gives coded representations of more than 230 names of countries or areas independent from countries. This document contains two-letter (Alpha-2-code), a three-letter code (Alpha-3-code) and a three-digit numeric code (Numeric-3-code) for every entry in its list of country names. This has been typically the document that IANA uses to create ccTLD entries in the root-zone system.
NACK: See “non-acknowledgement of transfer request”
Nameserver: A computer running software that authoritatively looks up the numeric equivalent (IP Address) of a record in a zone file, usually for the purpose of allowing remote client access to remote server resources over a network.
Namespace: All combinations of Domain Names and Top Level Domains, registered and otherwise, existing below the Root System.
NIC: Network Information Center.
NIC Handle: A NIC Handle is an identifier in use by some registrars and registries that is assigned to various records in the domain name database. Globally, they do not have a common format or application. Further, they are not globally unique.
Non-acknowledgement of Transfer Request [ NACK ]: In the process on transferring a domain name, the registrar from whom the domain is being transferred must approve or reject the transfer. In the protocol that supports this process the request to approve or reject at transfer request must contain a message with the word “Approve” and a value of yes or no. In the case where the transfer request is denied by the registrar from whom the domain is being transferred, we say that the transfer request was NACKed (denied).
Object: A generic term used to describe entities that are created, updated, deleted, and otherwise managed by a generic registry-registrar protocol. This includes nameserver objects, contact objects and other similar entities.
Registrant: See Domain Holder.
Registrar: A person or entity that, via contract with Domain Holders and a Registry, provides front-end domain name registration services to registrants, providing a public interface to registry services.
Registrar, Accredited: A Registrar that has been certified as meeting certain minimal criteria to act as a Registrar for a specific TLD. This term is almost solely used when referring to Registrars that have been certified by ICANN. ccTLD Registries also accredit registrars, and though they may use differing terms, the concepts are largely the same.
Registrar, Gaining: In a domain name transfer, the registrant changes the service that provides the front-end domain name service. The Gaining Registrar is the institution or organization that becomes the new registrar for the registrant.
Registrar Lock Feature: The registrar lock feature is a feature in inter-registrar communications that prevents unwanted registrar transfers and DNS object changes. The lock feature is aimed at providing registrars with a method to prevent DNS object transfers and changes that have not been approved by the registrant.
Registrar, Losing: In a domain name transfer, the registrant changes the service that provides the front-end domain name service. The Losing Registrar is the institution or organization that used to be the registrar and who is “losing” the service contract for registration services to the Gaining Registrar..
Registrar, Sponsoring: The Registrar responsible for the submission of the domain name to the Registry.
Registrar Operator: A term used to denote the entity providing the technical services to a Registrar in support of their registration services. Also referred to as a “Registrar Outsourcer” or “Registrar Provider”.
Registration Authority: The policy making body for any given TLD. Examples include the Canadian Internet Registration Authority, Nominet and MuseDoma.
Registry: A Registry is the person(s) or entity(ies) responsible for providing registry services. Registry services include customer database administration, zone file publication, DNS operation, marketing and policy determination in accordance with the general principles outlined in RFC 1591 [5]. A Registry may outsource some, all, or none of these services.
Registry, EPP-based: A registry that uses EPP (see “Extensible Provisioning Protocol”) as the mechanism communicating with the registrar.
Registry, RPP-based: A registry that uses RPP (see “RPP”) as the mechanism for communicating with the registrar.
Registry, Thick: A registry in which all of the information associated with registered entities, including both technical information (information needed to produce zone files) and social information (information needed to implement operational, business, or legal practices), is stored within the registry repository.
Registry, Thin: A registry in which some element of the social information associated with registered entities is distributed between a shared registry and the registrars served by the registry.
Registry Operator: Usually synonymous with the term Registry, however a Registry Operator may also be an organization or individual acting operating the Registry under an outsourced technical services management contract.
RRP: The registry registrar protocol: a set of specifications for a TCP-based, 7-bit US-ASCII text protocol that permits multiple registrars to provide second level Internet domain name registration services in the top level domains (TLDs) administered by a TLD registry. Unlike EPP, RRP is specified using Augmented Backus-Nauer Form (ABNF)
SLD: An "SLD" is a second-level domain of the DNS
SLD, Functional: A reasonable equivalent to an SLD in a namespace where second level domains are not permitted for policy reasons. An example of a Functional SLD would be foo.com.au. While .com is the actual SLD, .au policy does not permit the widespread registration of second level domains, thereby creating a proliferation of Functional SLDs (in this case .foo) in the .au namespace.
SLD Holder: See "Domain Holder"
SLD Sponsor: See "Registrar, Sponsoring".
Shared Registration System: A domain name registration system in which registry services are shared among multiple independent registrars. Shared Registration Systems require a loose coupling between registrars and a registry.
TLD: Top Level Domain. A generic term used to describe both gTLDs and ccTLDs that exist under the top-level root of the domain name hierarchy.
Top Level Domain: See “TLD”.
Top Level Domain, Country Code: A TLD that corresponds to an entry in the ISO-3166-1 list. .UK, .GG, .JE are also ccTLDs despite the lack of a corresponding entry in the ISO-3166-1 list.
Top Level Domain, Generic: A TLD created to act as a globally relevant resource. Examples of these include .COM, .NET, .ORG, .INFO, .BIZ and .AERO amongst others.
Transfer Authorization Record: Gaining registrars are required to maintain reliable evidence of express authorization by the Registrant or Administrative Contact of record. This transfer authorization record is in a standard format and may include information from the individual or entity that has apparent authority to execute the transfer request.
Whois: a TCP transaction based query/response server, that providing net wide directory service to network users. The Whois Protocol was originally defined in RFC 954. The initial domain name related application layer implementations were centralized systems run by SRC-NIC and then later InterNIC/Network Solutions. The SRI-NIC and InterNIC implementations are more formally referred to as "NICNAME/Whois" services. Whois is not purely a domain name or IP address directory service, but has been deployed for a wide variety of uses, both public and private. Other variants of this service include RWhois and the newer Verisign Referral LDAP Whois service. Whois can refer to the protocol defined in RFC 954 or the generic application service described above.
Whois, Bulk: A data retrieval mechanism required by ICANN that specifies that all ICANN accredited Registrars must make their Whois dataset available as a single machine readable file. Put another way, Bulk Whois is the entire Registrar Whois dataset available for retrieval via FTP, HTTP or some other mechanism. Thick Registries also may provide a similar service in allowing entities to retrieve the Registry Whois dataset.
Whois, Command-line: A Whois query executed from the command line of an operating system such as Linux or MS-DOS.
Whois Record: The information or payload returned to the client as a result of a Whois query.
Whois, Referral: RWhois (Referral Whois) extends and enhances the Whois concept in a hierarchical and scaleable fashion. In accordance with this, RWhois focuses primarily on the distribution of "network objects", or the data representing Internet resources or people, and uses the inherently hierarchical nature of these network objects (domain names, Internet Protocol (IP) networks, email addresses) to more accurately discover the requested information. [6]
Whois, Registrar: Whois services made available by specific registrars for the domain names that they sponsor at the Registry.
Whois, Registry: Whois services made available by specific registries for the domain names that they are authoritative for. Registry Whois often do not provide the comprehensive contact information that Registrar Whois services do, but they usually contain contact information for the Sponsoring Registrar. Note that the payload provided to the client by the Registry is not standardized between Registries and may vary based on the model employed by the Registry.
Whois, Web based: A World Wide Web interface to Registrar or Registry Whois services.
Zone: A portion of the total domain namespace that is represented by the data stored on a particular nameserver. The nameserver has authority over the zone – or the particular portion of the domain namespace – described by that data.
Zone File: A file that contains data describing a portion of the domain name space. Zone files contain the information needed to resolve domain names to Internet Protocol (IP) numbers.
III., cont’d.
Submitting comments: The Task Force asks that you provide your comments to the extent you can, including the numbers of the section you are commenting on. For instance, you might be commenting on General Provisions: 3,d,1. Using this approach will help the Task Force to better understand your comments.
We remind all that we value and seek your comments. Expressions of support and lack of support are important to help to advise the Task Force; however, we ask that you provide the argument regarding why you do not support. Mere statements of position as “supports” or “non support” aren’t very useful. Hearing what your concerns or questions are will be very helpful.
IV. IMPACT ANALYSIS:
This section is reserved for further analysis, which the Task Force is undertaking; The Task Force believes that they must finalize their recommendations, based on public comment, in order to complete the impact analysis.
V. CONSTITUENCY IMPACT REVIEW/COMMENTS:
Comments from Constituencies and the General Assembly are invited and will be summarized here. The actual submissions will be part of the Appendix/Link section. Individual comments are welcome and will appear in the following section.
VI. RECORD OF OUTREACH
The Task Force has undertaken some initial outreach, conducted two briefings of the Names Council, and held a few public conference calls. These are being documented in detail for this section, and further sessions, including the public comment period, and the outreach session in Shanghai, will be incorporated in this section.
VII. MINORITY POSITIONS:
The Task Force is aware that there is the possibility of minority reports. Any minority reports will be provided as attachments, in this section.
SUPPORTING ARGUMENTS
The section with draft recommendations includes most of the supporting arguments. For the Final Report, we expect to separate the recommendations and the supporting arguments, and to include them in this section.
RISK/COST ANALYSIS
In order to complete the cost/risk analysis, the Task Force agrees that they must have final recommendations; therefore, they will begin this process during the public comment period, so that they can best assess the risks and costs of the proposed solution.
PUBLICATION AND COMMENT PERIOD:
The Task Force directs that this be posted from 10/15 to 11/8, a period of approximately 3 weeks and three days. In addition to posting it via the DNSO list, we will seek the establishment of a public web based forum by ICANN. In addition, we will hold at least one open conference call to provide a further opportunity for feedback.
Comments will be summarized and presented here; copies will be archived to the Transfer Task Force web site, with a link from the relevant page in the document.
Appendix/links
Summary of Outreach - TBD
Transcripts of open calls
22/08/2002
29/08/2002
11/09/2002
02/10/2002