ICANN DNSO Transfers Task Force Final Report & Recommendations
Status: Final Report
November 30, 2002
(Last Updated: February 12, 2003)
Version Dec. 12: 20021212.NCTransferTF-gaining-and-losing-registrars.html
Version Nov 30: 20021130.NCTransferTF-gaining-and-losing-registrars.html
Note: On 02/12/03, this report was updated to include feedback received from the GNSO Transfers Implementation Committee. All changes adopted by the Task Force and included in this report are clearly marked for the record. No further changes were made to this document during this particular revision. On 12/12/02, this report was updated to include feedback received by the Task Force during the final public comment period and also to include a late submission by the Registry Constituency. The following sections of this document were updated and all additions are clearly marked:
|
When private sector competition was introduced into the registration functions of the generic Top Level Domains, the community greeted this concept with great enthusiasm and high expectations. Now that competition has been implemented, the community enjoys the benefit of having access to a healthy and diverse community of competitive Registrars who offer differentiated services, at different prices. They are located in different countries. Some work through ISPs, some sell direct. Some are “niche” providers, who actually primarily offer ISP or web hosting services, or the registration service is largely a courtesy but an important one, to their existing customers. To many, registration services are their core business. While this description does not do justice to the range of innovation of the competitive Registrars for gTLD names, it begins to capture the key and critical message: Registrants should be able to choose a Registrar who can serve their needs, and they should be able to “move” from one Registrar to another, if they are dissatisfied, for any reason.
But, can they?
As the Task Force examined the issues, it became apparent that it is difficult, if not impossible for self-interested parties to voluntarily agree on changes to the policy. In fact this has been attempted on more than one occasion and the experiences of Registrars, Registries, Registrants and the ICANN Staff demonstrate that the voluntary approach to solving these complex problems is not a valid approach to resolving the issues identified by the community. The practices of a single large Registrar can affect dozens of small Registrars, while actions by 2-3 of the largest Registrars means that choice is simply ‘on hold’. Despite several attempts at forging voluntary agreement on the necessary changes, the record shows that there are still problems with the “portability” of domain registrations – customer choice remains limited.
The outreach undertaken by the Task Force supports this view. ICANN staff has further acknowledged this. With this understanding the Task Force proceeded with one assumption: regardless of the reasons why a transfer is approved, denied, blocked, delayed, or misdirected, Registrants are entitled to transfer their registration from one Registrar to another and the process to do so should be easy, fluid, transparent, and inexpensive. When mistakes, errors, or fraudulent transfers happen, there should be a quick and simple “recovery” process available. There should be an appeal process to deal with the complicated situations. All of this should be clear, understandable, and speedy, and limit the time and financial investment of Registrars, Registries and Registrants.
The Task Force summarizes these requirements in four simple words; Security, Transparency, Stability and Portability. Any recommendation approved for implementation as policy must meet these four standards and achieve balance between them. The Task Force believes that its recommendations fulfill this obligation in all regards.
More broadly speaking, the characteristics that benefits Registrants should also provide benefit for Registrars and Registries. The Transfer Task Force has tried to approach the problems and concerns with that goal in mind—a mutually beneficial approach that ensures the satisfaction of the Registrants, Registrars and Registries. This system must enable a fair, balanced, competitive environment, provide Registrants with choice give them the capability to exercise that choice and provide Registries and Registrars with the safeguards necessary to limit their exposure, costs, and liability.
The Task Force engaged in extensive outreach to the impacted community over a number of months. Some accepted the invitation to provide input and comment, others did not. Registrars had legitimate concerns about abuse of a system which might mislead Registrants and cause them to agree to a transfer, which they didn’t understand. Others are concerned about “slamming”. Some raised questions about ‘customer fraud’. The Task Force dealt with these as serious concerns. The processes recommended provide an option for the losing Registrar to contact the Registrant for validation, should they suspect slamming or fraud.
If there is a single theme to the work of the Task Force, it is that the system of transfers between competitive Registrars is to serve Registrants. As you read our report, this theme should be kept in mind: Transferring domain name is about customer choice.
The Task Force has benefited 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.
Many individuals and companies shared their views and experiences with us. ICANN staff provided essential clarification and offered analysis of the existing agreements; Constituency and General Assembly members (and others) participated in open calls. Many dissenting and many supporting comments were received. The Task Force thanks all who spent their time in educating, agreeing, and disagreeing with their recommendations. We made every effort to reflect the input we received. We acknowledge that we may have missed some of the specifics but we believe that we have captured the themes and broad concerns.
As we enter the final comment period lasting eight days, Constituencies are asked to present Constituency Impact Statements. Others may choose to submit dissenting opinions or expressions of support. Any submissions on impact or minority opinions received will be included in that final submission, along with the comments of the Task Force.
This Final Report of the Task Force builds on previous reports that attempted to describe the nature of the problem. This report is built on the need for a change in process and describes high level principles to guide policy, provides extensive policy recommendations and documents where consensus exists and where it does not. Finally, it establishes some areas where unresolved work items exist. This report will be presented to the Names Council for acceptance and forwarding to the Board for agreement. We anticipate that there may be questions and stand ready to provide all assistance to the approval and implementation processes.
Submitted by the Transfer Task Force,
The Task Force respectfully submits the following policy recommendations to the Names Council for consideration as Consensus Policies in accordance with the standards set forth in the Names Council Rules of Procedure.
Unless noted otherwise, the Task Force believes that these recommendations are consistent with community consensus as it relates to the policy implications raised by the Task Force mandate.
Further explanation of these recommendations and documentation of the level of support that these policies have can be found elsewhere in this report.
There are many complex issues that derive themselves from the current policy on inter-Registrar domain name transfers. The Task Force does not believe that the issues can be substantively dealt with by a single policy pronouncement that magically rectifies the problems experienced by Registrars, Registries and Registrants.
Accordingly, the Task Force adopted an approach to formulating its recommendations that were rooted in conditioned principles upon which all stakeholder groups agree.
These principles fall into four broad categories;
The condition associated with these principles is equally simple: balance. The recommendations developed from these principles must provide sufficient balance between the often competing principles so as to ensure that the requirements of a broad range of stakeholders were adequately considered and dealt with. For instance, security at the expense of transparency would likely leave Registrants without a proper understanding of what processes they would need to engage in if they wished to move their name from one Registrar to another. Alternatively, recommendations that place too much emphasis on portability at the expensive of stability would leave most parties involved in the process without a predictable process by which they could easily remedy errors or proactively protect against them.
The recommendations contained in this report are the product of an open and transparent process that took place over the course of a year. Hundreds of hours of discussion were devoted to the topic, many proposals were considered, dozens of revisions were proposed and thousands of words debated the merits of specific recommendations and alternate approaches. In other words, a process took place by which the best recommendations were substantively discussed, clarified, compromised and eventually manifested themselves as the consensus recommendations contained in this report.
The Task Force believes that it is this approach, the process, which represents the single most compelling argument in favor of adopting these recommendations. The fact they do represent the best ideas of the community, the ones upon which we most agree and perhaps most importantly, the ones with the most understood and refined impact. This is not to say that concepts and ideas that did not make it into this report were not good or well-considered, to the contrary, there were many that were. But, these bright ideas did not get the support of the community necessary to include them as a consensus recommendation of this report. Similarly there were also many reasoned criticisms of these recommendations that were put forward. But, unless they were shared by a reasonable cross-section of the community, it was equally impossible to put them forward as the consensus of the community. This is one of the features of the consensus policy development process – both the consensus support and consensus disagreement must be substantively dealt with. Again, the Task Force believes that it has fulfilled this required.
However, we have no presumptions that new consensus ideas and dissent won’t emerge from the DNSO. Accordingly, we have attempted to temper these recommendations with very finite and predictable review mechanics that will allow the DNSO to adjust or correct the policy over the short, medium and longer terms. We believe that a moderate approach of this nature ensures that the policy in effect will continue to reflect the will of the community for the foreseeable future.
The consensus policy development process is neither easy nor trivial. Nor should it be. Appropriate processes lead to appropriate results. Balanced processes lead to balanced results. The Task Force believes that the processes employed in the development of these recommendations are both balanced and appropriate, but to the extent that the results need to be adjusted, a similarly balanced and appropriate approach should be taken so as to ensure the continued integrity of the results.
The Task Force has an obligation to ensure that the Names Council is informed of any significant implementation or operational concerns posed by the recommendations included in this report. The Task Force devoted substantial attention to the question of what constituted “significant implementation or operational concerns” and concluded that the most effective and practical definition was to analyse the policy recommendations from the standpoint of those parties that might be specifically impacted. Accordingly, Task Force representatives were asked to conduct an analysis that described what obstacles may exist as it relates to the implementation of these recommendations and any undue burden or unintended consequences that may occur as a result of the implementation.
This is further amplified in the General Cost and Risk statements and will be presumably be augmented by any Constituency Impact reviews received by the Task Force during the public comment period. The Task Force believes thatthis reports provides the Names Council with the supporting guidance necessary to accept these recommendations.
The Task force has made it clear that it accepts that the transfer process has a significant impact on Registrants, in offering them choice to more from one competitive Registrar to another, regardless of the reason that the Registrant has. Comments were received from ICANN staff and from Registrants themselves, as well as from Registrars and Registries, noting that Registrants can be harmed in several ways when a transfer is undertaken in error or for fraudulent purposes by some third party, or when a transfer is not undertaken as legitimately authorized/requested by the Registrant. Registrants have been required to renew with a Registrar they wish to transfer away from because they believe, or have been told that their registration may lapse. This renewal then holds them captive, until some other date when they may again be able to try to transfer. This may result in either loss of choice to the Registrant, or actually cost them additional registration fees when they renew, and then go ahead and transfer.
Registrants will benefit from a clear, transparent, documented approach for transfers, which limits fraud, or abuse, and which provides clarity about how they can pursue an authorized transfer. There are both “peace of mind” issues, but more importantly, actual economic and social impacts to a Registrant who is operating a web site for communicating with the public, and fears or risks, losing their domain name or having their site “go dark”, during a recovery period.
Registrants will need to be clearly informed, through communications both from ICANN via its normal distribution processes, as well as Registrars, of the changes in practices, based on policy changes.
This report contemplates many new and/or modified obligations that may or may not be fully understood by all Registrars. It will be important to ensure that ICANN and the DNSO are prepared to undertake outreach and education to ensure that all ICANN Accredited Registrars are aware of and compliant with these new and modified obligations. Some of the obligations contained in this report are more stringent than prior policies. This will require that Registrars ensure that their internal systems and processes are compliant with any policies enacted as a result of these recommendations.
Some of the recommendations contained in this report will require Registrars to modify their internal technical systems in a manner that will support any policies enacted as a result of this report. However, many Registrars already employ systems which already can, or with minimal enhancement could, comply with the recommendations made in this proposal. While the degree of modification will vary from Registrar to Registrar, the Task Force does not believe the costs incurred as a result of these modifications will be substantial. Further, anecdotal evidence suggests that the long-term benefits achieved through the implementation of standardized processes in some areas of the transfer process will result in increased consumer confidence and therefore outweigh any short-term costs involved.
Lastly, these recommendations do not attempt to provide specification concerning the type of technology and level of automation required to implement these recommendations. This is outside the responsibility of this Task Force. The Task Force agrees, however, that such changes may result in added costs to Registrars. During implementation discussions, further identification of cost areas can be undertaken by a joint working group of ICANN staff, Registrars, Registries and as needed, outside technical experts. The Task Force agrees to provide liaison support to such an effort, to represent the broader interests of users, as useful and appropriate.
Therefore, the Task Force believes that because; a) Registrars retain the capability to exercise a high degree of control over any costs that may arise as a result of these obligations and b) Registrars retain their right to engage in cost recovery under the terms of their operating agreements that the net total impact of these obligations is substantially limited.
(Note: This section was added 12-12-02) This report contemplates several new and/or modified obligations that will impact gTLD Registries and, as is the case with the gTLD Registrars, it will be important to ensure that ICANN and the DNSO are prepared to undertake outreach and education to ensure that all Registries and Registrars are aware of and compliant with these new and modified obligations.
Perhaps the recommendation with the most impact on the gTLD Registries is the possibility that they might serve as a dispute resolution provider in cases where Registrars either dispute a transfer or alternatively, the NACK of a transfer by the Losing Registrar. This may require gTLD Registries to supply new resources, including customer support and staff, that they do not currently provide. In addition, it may require gTLD Registries to engage in limited fact-finding investigations in an attempt to enforce the recommendations set forth in this report. Undoubtedly this may end up adding additional costs to the gTLD Registries which will be recoverable under the existing gTLD Registry Agreements with ICANN.
The Task Force does not believe the costs incurred as a result of these
modifications will be substantial in light of the report's efforts to
standardize the transfer process, thereby creating increased certainty for end
users, and ultimately portability of domain names. During implementation
discussions, further identification of cost areas can be undertaken by a joint
working group of ICANN staff, Registrars, Registries and as needed, outside
technical experts.
The risks and cost associated with this proposal are still to be fully defined, and the Task Force acknowledges that. Since the implementation period will develop further many aspects of “how” implementation may be done, and there will be areas of flexibility to individual Registrars, the Task Force believes that this step is more appropriately undertaken during the Implementation Process. Accordingly, the Task Force did not engage in an in depth analysis of the risks and costs associated with these recommendations beyond what is included in the “Impact Analysis” portion of this report.
While we feel that the Impact Analysis and Constituency Impact Reports will provide a high level identification of the current risks and costs, the Task Force believes that further risks or costs that have not yet been identified or fully documented in scope will only manifest themselves during the implementation and monitoring stages contemplated by the Consensus Recommendations of the Task Force. During the implementation period, these costs and risks should be documented and will need to be taken into account in the implementation period itself. Again, the Task Force assumes that costs may include both staff costs and systems costs.
There is likely to be additional ICANN staff demands, as well, and that costs will actually be easier to document, by asking the ICANN management to extrapolate from the time now spent by ICANN staff on addressing transfer concerns. Once a new and different process in place, and “tested” through actual practical use, it may be that demands on staff time will diminish. The Task Force is not sure that will happen in any near term, however, since there will undoubtedly be continued changes in the competitive Registrars “market”, with the usual changes which take place in a market sector, consolidation, expansion, mergers, growth of new Registrars, etc. Therefore, additional ICANN staff time and resources should be planned for by ICANN management.
Further, it is our opinion that once the initial costs are identified during the implementation period, these areas should become part of the periodic implementation reports that the Task Force recommends. These reports should also include documentation, however, on numbers of incidents, and impact on Registrants as well.
The Task Force did not receive any CI Reviews prior to the publication of this document. They will therefore be published as received and are incorporated by reference at the following URL:
http://www.byte.org/nc-transfers/ci/
(Note: As of 12-12-02, The Task Force did not receive any Constituency Impact Reviews.)
(Note: On 12-14-02, The DNSO Names Council unanimously approved the following resolution;
'The Names Council accepts the policy recommendations that were in the transfer Task Force Report of 30 November.
The Names Council will form an implementation analysis committee which will comprise of the Registries and Registrars with ICANN staff and user liaisons from the transfer task force.
That it will complete its analysis by 30 January 2003.
The Names Council will then meet to discuss the final ICANN Board report in its meeting in February and the final Board report will be forwarded with the aim to reach the ICANN Board 30 days prior to the ICANN meeting in Rio de Janeiro.
The report from the implementation analysis committee will present the findings on the feasibility of implementing the policy and it will be suitable for inclusion in the report which will become theTransfers Board report.'
On 01-31-2003, The Transfers Implementation Committee filed its final report with the GNSO Council pursuant to this resolution. This report can be found in its entirety in Exhibit D of this report.
The significant recommendations of this Implementation Commitee (Imp-Comm), along with an analysis by this Task Force are as follows;
Rec. #
|
Text of Task Force Recommendation & Suggested
Amendments of the Imp-Comm
|
Task Force Comments & Recommendations
|
1 | Registrants must be able 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.. | No change from existing Task Force recommendation. |
2 | Implementation of these conclusions and recommendations should, wherever possible, use existing protocols and standards. | No change from existing Task Force recommendation. |
3 | Existing Recommendation: Registrars must provide and maintain an email address for use by all other Registrars and registries where formal communications concerning the transfer process can be sent and dealt with by the receiving Registrar. |
Accepted with modification. Specifically that;
|
Suggested Replacement text: Registrars should provide a unique and private email address for use only by other registrars and the registry:
|
||
4 | Inter-Registrar domain name transfer processes must be clear and concise in order to avoid confusing Registrants or other stakeholders. | No change from existing Task Force recommendation. |
5 | Current recommendation: The Registrant must be informed of and have access to, the published documentation of the specific transfer process of their current Registrar. The Task Force notes that it would also be useful for Registrants to have access to the transfer process documentation of Registrars that the Registrant is considering switching to. |
Accepted with modifications. Specifically that the first sentence of the amendment be modified for the sake of clarity to read “Registrars should make reasonable efforts to inform registrants of and provide access to, the published documentation of the specific transfer process(es) employed by the Registrar.” |
Suggested replacement text: Reasonable efforts should be made to inform registrant of and have access to, the published documentation of the specific transfer process of their current registrar. The Task Force notes that it would also be useful for Registrants to have access to the transfer process documentation of Registrars that the Registrant is considering switching to. | ||
6 | In EPP-based gTLD Registries, Registrars must provide the Registrant with the Registrant’s unique “AuthInfo Code” within a reasonable period of time of the Registrant’s initial request. The Task Force observes support that this reasonable time period is 72 hours or a similarly limited period of time. | No change from existing Task Force recommendation. |
7 | In EPP-based gTLD Registries, Registrars may not employ any mechanism for a Registrant to obtain its AuthInfo Code that is more restrictive than what they require from a Registrant to change any aspect of its contact or nameserver information. | No change from existing Task Force recommendation. |
8 | Current recommendation: The Gaining Registrar must verify the intention of the Registrant or Administrative Contact of Record to transfer their domain name registration by requiring that the Registrant complete a valid Standardized Form of Authorization. | Accepted. |
Suggested replacement text: The Gaining Registrar must confirm a transfer request, by requiring that the Registrant or Administrative Contact of Record as listed in the WHOIS complete a valid Standardized Form of Authorization. A transfer must not be allowed to proceed if no confirmation is received. | ||
9 |
Existing Recommendation: The Gaining Registrar is solely responsible for validating Registrant requests to transfer domain names between Registrars.
|
Accepted. |
Proposed revised text: The Gaining Registrar is responsible for validating Registrant requests to transfer domain names between Registrars.
|
||
10 | Current recommendation: In the event that a Registrant has not confirmed their intent to transfer with the Losing Registrar and the Losing Registrar has not explicitly denied the transfer request in accordance with these recommendations, the default action will be that the Losing Registrar must allow the transfer to proceed. | Accepted. |
Suggested replacement text: In the event that a Registrant or Admin Contact listed in the WHOIS has not confirmed their request to transfer with the Losing Registrar and the Losing Registrar has not explicitly denied the transfer request in accordance with these recommendations, the default action will be that the Losing Registrar must allow the transfer to proceed. | ||
11 |
Existing Recommendation: If the Losing Registrar chooses to independently confirm the intent of the Registrant when the Losing Registrar receives notice of a pending transfer from the Registry, the Losing Registrar must do so in a manner consistent with the standards set forth in these recommendations of this report pertaining to Gaining Registrars. 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 Registrant’s decision(s) including the outcome if the Registrant doesn’t respond.
|
Accepted with modification. Specifically that;
"No Registrar shall add to the Standardized Form of Authorization or any form or application used to obtain the consent of the Registrant or Administrative Contact of Record, any additional information. The Standardized Form of Authorization should be sent as soon as operationally possible but must be sent not later than 24 hours after receiving the transfer request.” |
Suggested additional text:
|
||
12 | The presumption in all cases will be that the Gaining Registrar has received and authenticated the requisite request from the Registrant or Administrative Contact. | No change from existing Task Force recommendation. |
13 | Existing Recommendation: In instances where the Losing Registrar does not feel that the Gaining Registrar has obtained the requisite authorizations described in these recommendations, the Losing Registrar may file a dispute as described in the Reference Implementation | Accepted. |
Additional text: Either registrar should be able to file a dispute | ||
14 | Existing recommendation: 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 (the Losing Registrar has other mechanisms available to it to collect payment from the Registrant that are independent from the Transfer process.) . | Accepted. |
Additional text: Except for non-payment for previous registration period if transfer is requested after the expiration date, or non-payment of the current registration period, if transfer is requested before the expiration date. | ||
15 | In EPP-based TLDs, a Losing Registrar must not refuse to release an “AuthInfo Codes” to the Registrant solely because there is a dispute between a Registrant and the Registrar over payment. | No change from existing Task Force recommendation. |
16 | Existing Recommendation: 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 authority of the Registrant supercedes that of the Administrative Contact. | Accepted. |
Suggested Replacement text: The Administrative Contact and the Registrant, as outlined in the Losing Registrar’s or Registry’s (where available) publicly accessible WHOIS service are the only parties that have the authority to approve or deny a transfer request to the Gaining Registrar. In the event of a dispute, the authority of the Registrant in the authoritative Whois service supercedes that of the Administrative Contact | ||
17 | Existing Recommendation: The Gaining Registrar must use a Standardized Form of Authorization to seek the approval of the Registrant or Administrative Contact. |
Accepted with modification. Specifically that;
"The Gaining or Losing Registrar must use a Standardized Form of
Authorization to seek the approval of the Registrant or Administrative
Contact. English shall be the primary and default language for these
communications. |
Suggested replacement text: The Gaining or Losing Registrar must use a Standardized Form of Authorization to seek the approval of the Registrant or Administrative Contact. English is the mandatory default language for all registrar, registry and registrant transfer communications. Additionally, registrars may communicate with registrants in other languages provided that the principle of standardization this principle is satisfied | ||
18 | ICANN should support the development of this Standardized Form of Authorization through staff consultation with impacted stakeholders with guidance as to intent and scope from this Task Force. This form must be useable in both physical and online automated systems (web, email). | No change from existing Task Force recommendation. |
19 |
In the event that the Gaining Registrar must rely on a physical process to obtain this authorization, a paper copy of the Standardized 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.
|
No change from existing Task Force recommendation. |
20 | Existing recommendation: Gaining Registrars must maintain copies of the Standardized Form of Authorization by the Registrant or Administrative Contact of Record as per the standard document retention policies of the contracts. |
Accepted with modification. Specifically that;
" Each Registrar Therefore, the actual text of the specific recommendation will read as follows; "Gaining Registrars must maintain copies of the Standardized Form of Authorization by the Registrant or Administrative Contact of Record as per the standard document retention policies of the existing contracts. Each Registrar is responsible for keeping copies of documentation that may be required for filing and supporting a dispute resolution process." |
Suggested replacement text: Registrars are responsible for keeping copies of documentation required for filing and supporting a dispute resolution process | ||
21 | Existing Recommendation: Gaining Registrars must allow inspection by the Losing Registrar, and other relevant third parties such as ICANN, the Registry Operator or a third party Dispute Resolution Panel, of the evidence relied upon for the transfer during and after the applicable Inter-Registrar domain name transfer transaction(s). |
Accepted with modification. Specifically that;
"Gaining and losing registrars must allow inspection by the other registrar who is party to the transfer transaction (Gaining or Losing), and other relevant third parties such as ICANN, the Registry Operator or a third party Dispute Resolution Panel, of the evidence relied upon for the transfer during and after the applicable Inter-Registrar domain name transfer transaction(s)." |
Suggested Replacement text: Gaining and losing registrars must allow inspection by the matching registrar, and other relevant third parties such as ICANN, the Registry Operator or a third party Dispute Resolution Panel, of the evidence relied upon for the transfer during and after the applicable Inter-Registrar domain name transfer transaction(s). | ||
22 | Copies of the Reliable Evidence of Identity must be kept with the Standardized Form of Authorization. The Gaining Registrar must retain, and produce pursuant to a request by a Losing Registrar, a written or electronic copy of the Standardized Form of Authorization. The Losing Registrar retains the right to inspect this documentation at all times consistent with existing document retention requirements. | No change from existing Task Force recommendation. |
23 | In instances where the Losing Registrar has requested copies of the Standardized Form of Authorization, the Gaining Registrar must fulfill the Losing Registrar’s request (including providing the attendant supporting documentation) within a reasonable period of time from the receipt of the request. The Task Force recommends (3) business days. Failure to provide this documentation within the time period specified is grounds for reversal by the Registry Operator or Dispute Resolution Panel in the event that a transfer complaint is filed in accordance with the recommendations of this report. | No change from existing Task Force recommendation. |
24 |
Existing Recommendation: A Losing Registrar may deny a transfer request only in the following instances;
|
Accepted on the conditions ;
and that addition "i" be modified to read; "A domain name is within 60 days (or a lesser period to be determined)
|
There should be a finite list of allowable reasons for denying a transfer request with the understanding that procedures should be put into place to modify the list if registrars support any changes. Upon denying a transfer request for any reason, registrars must provide the registrant and the other registrar the reason for denial |
||
25 |
Instances when the Losing Registrar may not deny a transfer include, but are not limited to;
|
No change from existing Task Force recommendation. |
26 |
That Registrars have access to a suitable process(es) by which they can dispute any specific transfers that they might object to after the fact (i.e. – a dispute resolution processes as outlined in the Reference Implementation described elsewhere in this report). And that such processes specifically include provisions that fulfill the following requirements;
If the gaining registrar is responsible for transfer authentication and the losing registrar’s special Whois is not accessible for a to-be-specified time; this can be grounds to allow the transfer to occur in case of a dispute. |
No change from existing Task Force recommendation. |
27 |
Existing Recommendation: That Registries implement a “Transfer Undo” command that will assist Registrants and Registrars in resetting a domain name back to its original state in the event that a transfer has occurred in contravention of the recommendations of this document. |
Accepted. |
Suggested Replacement text: That Registries implement a “Transfer Undo” mechanism that will assist Registrants and Registrars in resetting a domain name back to its original state in the event that a transfer has occurred in contravention of the recommendations of this document. | ||
28 |
That the implementation and execution of these recommendations be monitored by the DNSO. Specifically that;
|
No change from existing Task Force recommendation. |
29 | Guidance. The Task Force has completed three supplementary documents (“Exhibit A, Reference Implementation”, “Exhibit B, Proposed Dispute Resolution Model” and “Exhibit C, Standardized Definitions”) in support of these recommendations. These exhibits are submitted as guidance to those that will be required to craft and/or implement the policies adopted as a result of these recommendations. | No change from existing Task Force recommendation. |
In the course of its work, the Task Force concluded that there were many generalized observations and considerations that, while not integral to the specific policy recommendations, were highly valued by the community and fully within the scope of the subject matter to be considered by the Task Force.
Accordingly, we call to the attention of the Names Council the following general principles. These principles are not formal policy recommendations of the Task Force, and are presented solely with the intention of furthering the understanding of the consideration undertaken by the Task Force and the community. These are solely advisory in nature and no comment is made, nor implied, as to whether or not these represent the formal consensus of any portion of the community. Further, it is important to note that these are not presented nor should be construed as alternative or competing recommendations to the Consensus Policy Recommendations of the Task Force.
The purpose of the Task Force on Transfers is to:
In early 2001, complaints began to surface from a
number of Registrars regarding denials of requested transfers, including
substantial delays and confusing responses.
Throughout July, August, and September, the Registrar Constituency developed and approved, within the constituency, a protocol for handling transfers, with the intent that this protocol would be followed by all accredited Registrars, thus giving certainty to the Registrant of what happens when they change Registrars, or when their designated agent changes Registrars on their behalf. . After extensive drafting and discussion, a final document with extensive guidance was produced, and put to a vote by the Registrars.
The outcome of the vote:
Of 40 registrars voting, 3 against, one abstention, and 36 supporting. The Registrar Constituency provides further detail on this topic at http://www.icann-registrars.org/. The vote held supported the default “ack” policy, which essentially means that the losing Registry transfers the Registrant, upon receipt of the request from the “gaining” Registry. |
However, in spite of the vote, there was not complete acceptance within the Registrars Constituency and at least one, and maybe more Registrars are not yet in compliance with the recommended procedure, as defined in the Registrar protocol for transfers.
When this situation came to the attention of
other constituencies prior to ICANN’s meeting in
The issue was brought to the attention of the Names Council on an ensuing
conference call (
Date |
Place |
Description |
Participants | |
|
In-person,
|
Joint Constituency Briefing |
Task Force
Rep., | |
|
In-person,
|
Registrar Constituency Briefing |
Task Force Rep., R’rarC | |
|
Teleconference |
Cross-Constituency Briefing |
Task Force, Open | |
|
In-person,
|
Registrar Constituency Briefing |
Task Force Rep., R’rarC | |
|
Teleconference |
Transfers Task Force Open Consultation |
Task Force, Open | |
|
In-person,
|
Registrar Constituency Briefing |
Task Force Rep., R’rarC | |
|
In-person,
|
Registrar Constituency Briefing |
Task Force Rep., R’rarC | |
|
In-person,
|
DNSO Names Council Briefing |
Task Force Chair, Names Council | |
|
In-person,
|
DNSO
|
Task Force, Open | |
|
Teleconference |
Transfers Task Force Open Consultation |
Task Force, Open | |
|
Teleconference |
Transfers Task Force Open Consultation |
Task Force, Open | |
|
Teleconference |
Transfers Task Force Open Consultation |
Task Force, Open | |
|
In-person,
|
Registrar Constituency Briefing |
Task Force Rep., R’rarC | |
|
Teleconference |
Transfers Task Force Open Consultation |
Task Force, Open | |
|
Teleconference |
Transfers Task Force Open Consultation |
Task Force, Open | |
|
Teleconference |
DNSO Names Council Briefing, |
Task Force Chair, Task Force Rep., Names Council | |
|
In-person,
|
Registrar Constituency Briefing |
Task Force Rep., R’rarC | |
|
In-person,
|
Transfers Task Force Open Consultation |
Task Force, Open | |
|
In-person,
|
Registrar Constituency Briefing |
Task Force Rep., R’rarC | |
|
In-person,
|
DNSO Open-Forum |
Task Force, Open | |
|
Teleconference |
Transfers Task Force Registrar Consultation |
Task Force Rep., R’rarC | |
|
Teleconference |
Transfers Task Force Open Consultation |
Task Force, Open | |
Public Comments on Task Force Interim Report,
October 16 - 30, 2002
(http://www.dnso.org/dnso/dnsocomments/comments-transfer/Arc01/)
Total number of posts as of |
13 |
Total number of substantive comments to the report[1]: |
5 |
Substantive comments include:
(Note: The following section was added 12-12-02 in order that the Final
Report included all comments received by the Task Force during its final public
comment period.)
Public Comments on Task Force Final Report, November 30
- December 8,
2002
(http://www.dnso.org/dnso/dnsocomments/comments-transfer/Arc02/)
Total number of posts as of |
9 |
Total number of substantive comments to the report[7]: |
6 |
Substantive Comments Include:
The Names Council Rules of Procedure specifies that any Consensus Policy Recommendations of a Task Force must include “a fair statement of points in opposition and a substantive analysis of their merits and the intensity of the opposition.”
While the Task Force has not, to date, received any substantive submissions that would qualify, classically, as a true “Minority Report”, the Task Force has received many inquiries and comments that would qualify for inclusion in this section of the report as per the standards for a “Minority Report” as set forth in the Names Council Rules of Procedure.
This portion of the Final Report is presented in “Questions & Answer” format focusing on the inquiries and comments that the Task Force received, informally and formally, throughout the term of the Task Force. We believe that each of these implications is substantively addressed by the Policy Recommendations of the Task Force and this report. Each answer to these questions is accompanied by an analysis of the merit and intensity of the objection presented.
A. Throughout the evolution of this issue and the ensuing work of the Task Force, a number of proposals have, and continue to, surface with the intention of dealing with the concerns raised by the community. After thorough examination of the issues and approaches, the Task Force did not believe that any of these alternate proposals substantively deal with the entire breadth and depth of the issues and therefore do not represent complete or supportable (by consensus) solutions. In developing the recommendations included in this Final Report, the Task Force analysed as many of these proposals as possible, taking into account that there were several periods during which substantive comments and proposals could have been submitted notwithstanding, that some of the proposals were received long after the close of public comment periods, (they continue to surface including as recently as 11/27/02). Where supported by community consensus, the principles and policies embodied in these alternate propositions were included in this report to the maximum extent possible.
Recognizing that the development of these policies has taken an inordinately long period of time due to the complexity of the issues and that the DNSO wishes to resolve these issues within a reasonable period of time, the Task Force has explicitly recommended a framework for the review of the implementation of any policy adopted as a result of this document at various set time frames by the Names Council and its successor bodies. These review requirements are intended to ensure that ICANN can continue to refine the new consensus policies while learning from their implementation.
Analysis:This concern was raised on a very a limited basis. Given the limited visibility that the Task Force has had to some of these alternate proposals, and the limited involvement that the broad community has had in developing or in any way participating or commenting on these alternate proposals, the Task Force does not feel that this comment can be considered a reasoned opposition to the recommendations of the Task Force. |
A. There is a substantial difference between creating policy recommendations that clearly outline a predictable process that engenders Registrant, Registrar and Registry confidence and one that attempts to define all aspects of the transfer process. In attempt to address this particular concern, the Task Force primarily concentrated on fulfilling the requirements imposed by the former. Recognizing that dealing in terms that are easily understandable by the broad range of impacted parties, the Task Force created a list of standardized definitions that should address this concern. Further, the Task Force has also provided information in several exhibits which we recommend to the Implementation Process. These are presented as “informational” only, although they represented extensive work by the Task Force and take into account many hours of consultation.
Analysis: Crafting recommendations that not only dealt with the substance of the policy, but the definable terms of the industry were not within the scope of this Task Force. The Task Force feels that the implied need for a high-degree of clarity with these recommendations as raised by this type of inquiry was heard by and dealt with by the Task Force. Concerns of this nature were expressed on an extremely limited basis. Other concerns were heard that the Task Force work may be too detailed. The Task Force has attempted to balance what it sees as the scope of work of a Task Force in recommending policy, has provided informational background and other outputs of its work, but has limited the recommendations to higher level statements. |
A. During the course of developing these recommendations, the Task Force devoted significant time and attention to understanding not only the notion of Apparent Authority as it is embodied under the existing transfers related policies, but also in trying to understand the intent of these policies. The Task Force took into account the comments, which were from a limited number of submitters, regarding “apparent authority”, sought guidance from ICANN legal staff and engaged in extensive examinations of its usefulness. As a result of this deliberation, the Task Force came to the decision that the notion of “Apparent Authority” was not sufficiently precise to provide Registrants, Registrars and Registries with the transparency, security, reliability and predictability in the transfer process that is necessary to satisfy the needs of the broadest possible range of impacted parties. Accordingly, the concept of “Apparent Authority” has been replaced by a much narrow range of entities that are authorized to approve a transfer.
Analysis: The Task Force believes that the range of recommendations intended to replace the notion of Apparent Authority are reasonably exhaustive and directly address the requirements of the community. Further, the Task Force did not receive substantial objection to this range of recommendations outside of the concerns raised by an individual several times in the process, and a minority number of total accredited Registrars[2] as a result of the public comment period following the publication of the Draft Interim Report. Signatories to this document include Register.com, Verisign and other “top 20” Registrars, but did not include a majority of Registrars, or “top 20” Registrars for that matter. The Task Force notes that this group of Registrars raised concerns predicated on the concept that some notion of “Apparent Authority” would continue to exist within the policy going forward. Given that these recommendations explicitly abandon all notions of “Apparent Authority” and replace it with much more stringent “proofs of authorization” the Task Force concluded that these concerns were addressed by the Task Force recommendations. |
A. The Task Force heard a broad range of concerns voiced by parties across all stakeholder groups that indicated that insofar as “gaming” was occurring in contravention of established policies, or where policy did not exist, that the Task Force should attempt to address the implications raised by this behavior in a pro-active manner. Accordingly, the Task Force recommendations attempt to fill as many policy gaps as possible whilst not unduly impacting any specific group in a negative manner. Broadly speaking, the Task Force accomplished this through two means; a) clarifying that it was the Gaining Registrar that is obligated to verify the intent of the Registrant and b) limiting the range of reasons why a transfer should not be approved. Given that the Task Force understood from the user communities that it was these two areas that were most affecting their capability to effectively transfer their domain names under the current policy[3] we have every reason to believe that the recommendations made in these two areas will address the broadest possible range of issues while reserving maximum flexibility of implementation for Registries and Registrars.
Analysis: It is impossible for any policy to be fool-proof, i.e. – “non-gameable”. Inappropriate implementation of policy, or worse, abuse under a specific policy will only occur insofar as the potential gain to be obtained by the abuse exceeds any penalties that might be incurred as a result of being caught as an abuser. The current policies governing transfers do not contain any penalties, save loss of accreditation. Therefore, in most cases, the gain to be had as a result of an infraction often outweighs any possibility that single applicable penalty could be applied. While this concern is widely held in the community, the Task Force believes that it is also the consensus of the community that the measures taken under these recommendations will effectively address these concerns. In the event that serious problems still exist, the proposed evaluation process will identify those and enable further work to be undertaken, as recommended by the Names Council. |
A. The proposed policy limits the number and type of entities that can verify the intention to transfer to the Administrative Contact or the Registrant. Therefore, if the Registrant wishes to provide a third party with the capability to acknowledge or deny transfer requests from Gaining Registrars, the Registrant should designate this third party as being the Administrative Contact of record. The Task Force heard from a limited number of entities about their concerns, but also their support for the need for an effective process. Such comments are part of the record of consultation.
Analysis: This concern was raised by a limited number of entities. However, those that did raise this concern would be drastically affected by the impact of this report with the absence of this capability. The Task Force considers these concerns reasoned, and believes that the recommendations contained in this document suitably address the needs of this group of stakeholders. |
This is essentially the same question as question 5. Registrants must understand what they are delegating to a third party. We believe that this question is a reasoned one, and that the solution proposed addresses it. In addition, where the Registry uses auth-info codes, the Registrant would be free to share that code with the entity they designate to act on their behalf.
A. Various classes of Registrants were consulted through during the development of this report through the outreach marked in other portions of this document. Further, most, if not all, classes of users were directly represented through representative membership on the Task Force. Classes of Registrants that were not directly represented were specifically sought out by the Task Force to ensure that the recommendations were appropriate for their needs. Because of our concerns about Registrants, the Task Force held numerous outreach sessions. At some point, the Task Force needed to determine that they had gathered sufficient input about the impact on Registrants to make policy recommendations.
Analysis: The Task Force believes that all classes of Registrants were adequately represented and consulted through the development of the policy recommendations contained in this report.. |
A. Specifically, yes. This dynamic is addressed in two ways. First, the report recommends a dispute resolution process by which Registrants can work with their Registrar to have their problems formally resolved according to a predefined process. The Task Force envisions that this process will be substantially similar to the current Uniform Dispute Resolution Policy. Secondly, the Task Force also recommends that gTLD Registry Providers augment their business capabilities with an “undo function” that would return the domain registration to a previous state that would be, in all respects, functionally identical to the state that the domain name was in prior to any errors or meddling that may have occurred.
Analysis:: This concern was raised by a number of Registrants and Registrars. The Task Force finds this concern reasonable in every regard and believes that the recommendations set forth fully address these concerns and reflect the consensus of the community. The Task Force did not specifically address how the Dispute Resolution process would be finally developed, or who would offer it. The Task Force does provide as an Appendix a possible “model”, based on the work of the Task Force to fully understand the issues involved. This is presented as “informational” only. |
A. Through extensive discussion within the Task Force and further consultation with the community after the Interim Report, the Task Force formed a minor series of amended recommendations that simply requires Registrars to provide Registrants with simple and transparent mechanisms by which Registrants can simply unlock or lock their domain name using accessible processes established by the Registrar.
Analysis: The Task Force heard this concern from several user groups. Earlier versions of this report contained substantially more stringent recommendations, however further discussion within the Task Force and outreach to various stakeholders within the DNSO only drew the lack of consensus on the older recommendations into focus. Accordingly the Task Force re-crafted its recommendations in order to support the principles that were supported by consensus. |
A. While more stringent processes such as those described in this question might arguably create a more secure environment for Registrants; overly strict processes do not provide the requisite levels of portability that Registrants have clearly voiced strong preference for. The key to any successful transfer policy lies with striking a balance between the security and stability requirements of Registrars, Registries and Registrants with the transparency and portability requirements of these same groups. Comments were heard by the Task Force in objection to the cost and inconvenience of notarized statements, as well as expressions by some Registrars about wanting to require such documents. Some concerns were also raised about requiring individuals, even when representing a company or organization, to fax in copies of personal driver’s licenses, which may include social security numbers, etc.
Analysis: This concern was primarily raised by a minority of larger Registrars. While the proposed recommendation may have some benefits for Registrants, this was not been supported by quantifiable data, or echoed in the requirements set forth by Registrants. Accordingly, the Task Force opted instead to strike an appropriate balance between security and portability rather than moving too far in either direction. |
A. The Task Force believes that the membership of the Task Force has a thorough understanding of the broad range of issues raised by the community in various forums. This was accomplished through the various open briefings, mailing list participation, public consultations, teleconferences and outreach sessions that the Task Force membership conducted and involved themselves in throughout the DNSO. Several Task Force members are members of the General Assembly, for instance. And, the General Assembly itself is represented on the Task Force. As other discussions were made public, the Task Force tried to avail itself of such information.
Analysis: The Task Force has considered whether or not it has gathered and analysed sufficient input from the community and feels that the understanding of the Task Force, augmented by the extensive outreach and consultation undertaken is sufficiently broad and representative as to ensure appropriately formed conclusions. This concern was raised by a substantially limited number of parties. |
A. The specific actions of “ack” or “n’ack” in and of themselves neither encourage, nor discourage fraudulent activity and the Task Force continues to question the basis for such conclusions. The Task Force does however believe that the processes employed in conjunction with default “ack” or “n’ack” processes by the various parties involved in a transfer transaction may lead to higher or lower incidences of fraud. Whether these processes lead to higher or lower incidences of fraud are solely dependent on whether or not appropriate behaviour is incented or discouraged. Given the overwhelming stated need for portability coupled with balanced security, the Task Force determined that there is consensus support for a default “ack” policy coupled with strong authentication and enforcement measures. Default “ack” was almost universally preferred over the alternatives due to the enhanced portability and stability that it offered Registrants, the similarity of the process to existing policy and the relatively low complexity and impact that the processes posed in comparison to the alternatives.
Analysis:: This argument was most often presented by proponents of the default “n’ack” policy. The Task Force took into account the concerns expressed that fraudulent transfers or “slamming” were serious and substantial in number. The Task Force agrees that fraudulent or slamming transfers are a serious concern. The research presented by the proponents of “n’ack” and discussions with ICANN staff did not bear out a concern that there are overriding numbers of such occurrences. The Task Force still takes such complaints and concerns seriously. Given that the behavior of the losing Registrar is but one aspect to a comprehensive policy recommendation and that users voiced a strong preference for an appropriate balance between security, portability, transparency and stability the Task Force chose to deal with the more holistic approach set forth in the Registrar Constituency submission to the Task Force[4]. The Task Force also recommended a mechanism for a concerned losing Registrar to contact the Registrant. The Task Force notes that ICANN staff are in a good position to fully understand the kinds of complaints which exists about transfers, and that the ongoing review process should include periodic reports by ICANN staff to the Names Council/its successor of the kinds of transfer problems which are occurring. |
A. The Task Force was tasked to consider the
very narrow issue of transfers. Where possible, the Task Force attempted to
craft recommendations which addressed the complaints the Task Force received
about how certain communications led to an undesired transfer by the
Registrant. Our recommendations are targeted at transfer process, not
marketing practices. Based on substantial input from Registrars, Registries
and Registrants, the Task Force specifically recommended that standardized,
transparent processes and documents be employed where appropriate. The Task
Force believes that this strikes a reasonable balance between the concerns
raised and the scope of the mandate of the DNSO Policy Development process and
this Task Force. The Task Force notes that as usual, complaints about
deceptive marketing should be referred by ICANN staff, or the Registrant, or
even another Registrar or Registry who becomes concerned to the appropriate
legal authority, such in the
Analysis: This concern was raised in a letter received from a group of Registrars. The Task Force does not believe that it is particularly well-founded given that it primarily questions why the Task Force did not craft recommendations that were specifically outside the mandate of the Names Council. Regardless, the Task Force believes that where appropriate, it has dealt with the potential that the transfer process can be abused using questionable marketing tactics by requiring the implementation of several standardized processes as set forth in the reasoned requirements of the Registrar, Registry and Registrant groups. |
A. The Task Force took this complaint seriously and tried to establish some degree of quantification or documentation from the concerned entities and the ICANN staff. In the end, the Task Force did not have any data to support the stated conclusion. Despite repeated requests, this claim was never quantified in any meaningful manner and was in fact specifically countered by data provided by ICANN staff that indicated that the volume of complaints concerning the inability of Registrants to transfer their domain names in a timely manner vastly outweighed any complaints of fraudulent activity.
Noting that the implications posed by the fraudulent transfer of domain names (i.e.: slamming & hijacking), the Task Force concluded that strong enforcement and remediation processes would be desirable. Consultation with the community confirmed strong consensus support for this approach.
Analysis: This concern was repeatedly raised by the proponents of the default n’ack policy. Given that the Interim Report as well as the Final Recommendations of the Task Force has consistently included strong remedial functions designed to ameliorate the effects of fraudulent transfers, the Task Force concluded that this concern was not sufficiently documented, and therefore not sufficiently reasoned to substantially consider in this Final Report. See other comments above in Question 12. |
As noted elsewhere in this analysis, default “n’ack” addresses only one relatively uncomplicated aspect of the larger policy issue and does not meet the broader needs stated by the larger community. Further, existing policy, as has been continuously demonstrated throughout this policy development effort, does not provide strict enough standards or the requisite enforcement function to make the policy truly useful. It must be acknowledged that there are high numbers of complaints about the present ‘auto –n’ack” practices, not only from Registrars, but from Registrants. These complaints led to the creation of the Task Force and efforts to understand how to revise policy in the first place.
Analysis: Again, this contention was put forward by the Registrars that are “auto-n’acking”. As noted elsewhere, this contention that there are high numbers of fraudulent transfers was not sufficiently supported in a quantifiable manner by its proponents and the Task Force was therefore unable to consider it as a “reasoned” proposition. The evaluation process should enable the ability to determine what volume actually exists in terms of fraud, slamming, etc. |
A. First, “apparent authority” is replaced by a better defined process for determining who can authorize a legitimate transfer. Secondly, where auth info codes are used by the Registry, these provide additional safeguards. Finally, and very importantly, the recommendations specifically describe a number of remedial procedures that will allow a Registrant or Registrar to “right” any wrongs caused as a result of any intentional or unintentional infractions of policies implemented as a result of these obligations.
Analysis: While the recommendations presented in this report do provide remedy for intentional or unintentional violations of these recommendations, the Task Force does not adequately understand all of the concerns raised by this objection, and, despite repeated requests for clarification, was not provided with a clear understanding of this objection. Specifically, The Task Force recommendations eliminate the notion of Apparent Authority, restrict the number of entities that can approve a transfer request, standardize the process by which a Gaining Registrar verifies such a request and specifically states that transfers may not occur without the express consent of an authorized entity. The Task Force takes concerns of this nature seriously, but did not receive clarification from those raising the objection, and therefore, the Task Force is unable to appropriately analyse these contentions or consider them in this Final Report. |
A. As was explained in the Executive Summary, the Registrar Constituency is but one stakeholder in this process. Further, the Task Force spent more than a year in consultation with the community exploring the full range of alternatives. While we cannot evaluate proposals that we have not received, we strongly feel that the time to implement changes which are supported broadly by the community is now and believe that these recommendations are reflective of community support and consensus
Analysis: This contention was raised by the opponents of the Interim Report that were signatory to the Ruiz et al document. The Task Force invested significant time and effort in seeking to understand the concerns of these parties, in consulting with these parties and others, and exploring the specific proposals that they developed or participated in the development of. Perhaps most importantly, the substantive recommendations that this group did put forward are extensively dealt with by this report. The Task Force does not therefore believe that further delay spent exploring further alternatives in any way benefits the community. This does not appear, on its face, to be a reasonable request requiring further consideration by the Task Force. |
A. New and amended policy usually requires the alteration of relevant contracts in some manner. The Task Force does not have the legal expertise, or the mandate to determine whether or not implementing these policy recommendations would require “significant alterations” to the existing contracts, nor even what contracts would need to be amended in order to achieve these objectives. We benefited from guidance from the General Counsel, and ICANN staff regarding some of the areas where consensus policy could require contract or Registrar Accreditation Agreement changes. However, again, the Task Force itself believes that it should not be engaged in legal analysis to the extent that the question implies. As to whether or not impacted (contracted) parties should have the opportunity to amend or negotiate these provisions before they are included in the contract, the Task Force notes that these recommendations are the consensus position of the community and therefore should be implemented as written with the exception of specific implementation details which should be left for the ICANN Staff and contracted parties to consider, document and implement. The Task Force also believes that if significant changes are made to the consensus policy recommendations during implementation, such changes should be reviewed with the Names Council/its successor. Otherwise, affected parties who are users would not be considered in such overriding changes, nor have a chance to comment. The question as presented seemed to consider that only Registrars or registries may be “affected parties”. The Consensus process of the DNSO and its successor requires that the input and concerns of a broad range of stakeholders be taken into account.
Analysis: This contention was solely raised by the signatories of the Ruiz et al document. Given the limited mandate of the Task , the importance of relying upon ICANN staff for such analysis and counsel, and overall the policy implications of this matter, the Task Force does not find this to be a reasonable submission. |
A. The answer to this question is dependant on the definition of “significant”. As cost and impact are relative considerations, there is no single answer to this question. The answers depend on the size and capability of each specific Registrar or Registry and the processes they currently employ. The Task Force believes that;
Further, the Task Force recognizes that Registrants, Registrars and Registries will all be impacted by these recommendations but that over the long term these will be largely social in nature (i.e. – education as to the nature of the revised policies) and will be outweighed by the economic effects created by predictable, stable, transparent and secure policies that engender the confidence of Registrants, Registrars and Registries.
Analysis: The Task Force notes that its consideration of cost and impact on affected parties is limited by the Names Council Rules of Procedure and but that its consensus policy recommendations must ensure that “…the Registrar or Registry operator has reasonable protections in its business from the effects of having to implement the policy, such as a reasonable time to implement the policy and a reasonable opportunity to pass on any costs of implementing the policy to its customers.”[5] The Task Force is not aware of similar conditions that would provide Registrars with a “last chance” opportunity to renegotiate what the DNSO consensus recommendations mean. To the contrary, Registrars have specific obligations to adopt consensus policies ratified by ICANN and have every opportunity to participate in the development of these recommendations. Given that the “contracted parties” have full opportunity to pass on any costs that may arise from the implementation of these recommendations and that no specific “deadline for implementation” is determined by these recommendations the Task Force does not find that this concerned is reasoned. Further, given that this concern was set forth by Registrars expressing concern for Registrants, one should conceivably be able to uncover parallel concerns voiced by the Registrant community. The Task Force received substantial comment from the Registrant community that indicated that the total cost of ownership of a domain name was but one small component of their consideration. Understanding that this concern was solely raised by a subset of Registrars, the Task Force does not find sufficient support for this notion to give it significant weight within the recommendations of this report. |
Broitman, Elana. “[Registrars]
Registrar transfers.” Online Posting.
Cochetti, Roger. “Letter from Roger
Cochetti to Stuart Lynn.” ICANN.
Rader, Ross. “Inter-Registrar Domain
Name Transfers Process Description & Overview.” Proposal for
Standardized Inter-Registrar Domain Transfers.
Broitman, Elana, and Ross Wm. Rader.
“Inter-Registrar Domain Name Transfers; Principles & Processes for
Gaining and Losing Registrars.” ICANN-Registrars.
Gomes, Chuck, and Elliot Noss.
“Mediated Authorization”. DNSO Registrar Constituency Mailing List
Archives.
Gomes, Chuck et al. “[Registrars] Fw:
Principles.” Online Posting.
The following section is intended to act as a descriptive guide to the processes outlined in the previous.
Losing
Registrar
Process
The following section is intended to act as a guide to the processes outlined in the previous diagram.
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.
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 that 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 “Standardized Form of Authorization”
GTLD: See “Top Level Domain,
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
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:
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.
Standardized 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 "Standardized Form of Authorization" (FOA) The acronym stems from legacy applications but has been preserved for the sake of continuity and ease-of-understanding.
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,
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 netwide 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.
This document provides:
Organization of the Analysis
The analysis is mostly contained in two tables. In Table 1 contains an assessment of whether the Transfers Task Force recommendation is implementable, the relative cost of implementation, and the level of support from registrars.
Table 2 contains information on issues associated with the recommendations that will need to be considered during implementation, and also where appropriate additional or alternative text to strengthen or clarify the existing recommendation.
# - The number of the recommendation made by the GNSO Transfer Task
Force (1-29)
Cost - What is the cost impact if the recommendation is implemented?
(high/medium/low/?)
Enf - Is the recommendation enforceable if it is implemented? (yes/no/?)
Feas - Can the recommendation reasonably be implemented from a process
point of view? (yes/no/?)
Supp - What is the anticipated level of support for the recommendation
from registrars? (high/medium/low/?)
Tech - Can the recommendation be reasonably implemented from a technical
point of view? (yes/no/?)
N/A - Not applicable
Table 1
|
|||||
# | Cost | Enf. | Feas. | Tech | Supp. |
1 | Low | Yes | Yes | Yes | High |
2 | Low | Yes | Yes | Yes | High |
3 | Low | Yes | Yes | Yes | High |
4 | Low | Yes | Yes | Yes | High |
5 | Low | Yes | Yes | Yes | High |
6 | Low | Yes | Yes | Yes | High |
7 | Low | Yes | Yes | Yes | High |
8 | Low | Yes | Yes | Yes | High |
9 | Low | Yes | Yes | Yes | Med. |
10 | N/A | Yes | Yes | Yes | Med. |
11 | N/A | Yes | Yes | N/A | Med. |
12 | N/A | Yes | Yes | N/A | Med. |
13 | Med | Yes | Yes | Yes | High |
14 | N/A | Yes | Yes | Yes | Med. |
15 | N./A | Yes | Yes | Yes | Med. |
16 | N/A | Yes | Yes | Yes | High |
17 | Low | Yes | Yes | Yes | High |
18 | Low | Yes | Yes | Yes | High |
19 | Med | Yes | Yes | Yes | High |
19a | Med. | Yes | Yes | Yes | High |
19b | Med. | Yes | Yes | Yes | High |
19c | Low | Yes | Yes | Yes | High |
20 | Low | Yes | Yes | Yes | High |
21 | N/A | Yes | Yes | Yes | High |
22 | Low | Yes | Yes | Yes | High |
23 | Med. | Yes | Yes | Yes | Med. |
24 | N/A | Yes | Yes | Yes | Med. |
25 | N/A | Yes | Yes | Yes | Med. |
26 | Med. | Yes | Yes | Yes | High |
27 | Med. | Yes | Yes | Yes, with constraints | Med |
28 | Med. | N/A | Yes | N/A | Med. |
28a | Med. | N/A | Yes | N/A | High |
28b | Med. | N/A | Yes | N/A | High |
29 | N/A | N/A | N/A | N/A | N/a |
Table 2 Detailed implementation analysis
|
||
Rec. #
|
Text of Task Force Recommendation & Suggested
Amendments of the Imp-Comm
|
Comments and issues
|
1 | Registrants must be able 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.. | The Registry operators and ICANN should consider methods for improving the testing of a registrar's transfer processes to ensure that their implementation is in compliance with the transfer policy. This testing could be done at the time of initial accreditation, or as part of an audit process. |
2 | Implementation of these conclusions and recommendations should, wherever possible, use existing protocols and standards. |
There are two primary registry to registrar protocols in use. RRP - developed by Verisign and used for com/net/org Where system changes (which could include software, legal or business process changes) are required at either the registry or registrars, a reasonable period of time (e.g 3 months) would be required to reach full compliance. Verisign notes that in some cases, software changes may take up to 6 months from an initial high level idea to include time to complete detailed specifications, software development, testing and deployment. |
3 | Existing Recommendation: Registrars must provide and maintain an email address for use by all other Registrars and registries where formal communications concerning the transfer process can be sent and dealt with by the receiving Registrar. |
To facilitate timely and effective communications between registrars regarding the transfer process, a unique and private address should avoid problems that might occur when mixed with other email traffic. |
Suggested Replacement text: Registrars should provide a unique and private email address for use only by other registrars and the registry:
|
||
4 | Inter-Registrar domain name transfer processes must be clear and concise in order to avoid confusing Registrants or other stakeholders. | |
5 | Current recommendation: The Registrant must be informed of and have access to, the published documentation of the specific transfer process of their current Registrar. The Task Force notes that it would also be useful for Registrants to have access to the transfer process documentation of Registrars that the Registrant is considering switching to. |
The TF recommendation says, "The Registrant must be informed of . . ." It is not always possible to ensure that a registrant is informed so this part of the TF recommendation could not reasonably be implemented or enforced. The transfer process could be included in the terms and conditions of the registration agreement. Information to registrants (and registrars) may be improved by ICANN providing a central registry of the transfer processes for each registrar to ensure that each registrar had a documented process. This may consist of links to the relevant transfers policy listed on the registrar website. Some registrars are adding additional constraints to when transfers can occur into their terms and conditions. A registrar should not be able to add conditions in addition to those listed in recommendation 24, that may limit competition and attempt to lock in the consumer to a particular provider. |
Suggested replacement text: Reasonable efforts should be made to inform registrant of and have access to, the published documentation of the specific transfer process of their current registrar. The Task Force notes that it would also be useful for Registrants to have access to the transfer process documentation of Registrars that the Registrant is considering switching to. | ||
6 | In EPP-based gTLD Registries, Registrars must provide the Registrant with the Registrant’s unique “AuthInfo Code” within a reasonable period of time of the Registrant’s initial request. The Task Force observes support that this reasonable time period is 72 hours or a similarly limited period of time. |
Many registrars have not properly implemented the EPP Protocol which incorporates an AuthInfo password for each domain name. To initiate a transfer a registrant must supply the AuthInfo password to the gaining registrar. The issue is that many registrars have not implemented procedures to allow a registrant to easily obtain the AuthInfo password associated with the domain name. The protocol allows for the user to select their own AuthInfo password, but the common implementation involves registrars creating this AuthInfo password on behalf of the registrant, and only provided the password to the registrant on request. It would be useful for registrars to settle on a common approach for retrieving the AuthInfo password, so that gaining registrars may instruct a registrant on the procedure to follow to retrieve the AuthInfo password. In any case the procedure for obtaining the AuthInfo password should be incorporated in the documentation for the transfer process discussed in recommendation 5. |
7 | In EPP-based gTLD Registries, Registrars may not employ any mechanism for a Registrant to obtain its AuthInfo Code that is more restrictive than what they require from a Registrant to change any aspect of its contact or nameserver information. | |
8 | Current recommendation: The Gaining Registrar must verify the intention of the Registrant or Administrative Contact of Record to transfer their domain name registration by requiring that the Registrant complete a valid Standardized Form of Authorization. |
The current wording uses "verify the intention of the Registrant". This may be difficult to implement legally. The replacement text uses the word "confirm", to indicate that the registrant/admin contact listed in the WHOIS should explicitly confirm the request. In most cases a registrars' only contact with the registrant is via a website, where the registrant has provided their contact details. There is no other information available to identify the registrant (ie no finger prints, or company incorporation documents etc) to verify the intention of the registrant. Many registrars for security reasons also do not retain credit card information. The last sentence makes it explicit that a transfer must not be allowed to proceed if no confirmation has been received. |
Suggested replacement text: The Gaining Registrar must confirm a transfer request, by requiring that the Registrant or Administrative Contact of Record as listed in the WHOIS complete a valid Standardized Form of Authorization. A transfer must not be allowed to proceed if no confirmation is received. | ||
9 |
Existing Recommendation: The Gaining Registrar is solely responsible for validating Registrant requests to transfer domain names between Registrars.
|
From a customer service point of view, it would be useful for the gaining registrar to know in advance that a losing registrar will also independently confirm the Registrar's intent. One possible implementation would be for the registry to maintain a table showing for each gaining/losing registrar pair, whether the losing registrar will independently confirm the Registrant's intent. Given that many registrants will receive two confirmation messages (first from the gaining and then from the losing), a further customer service improvement could be achieved by cooperating pairs of registrars to allow a losing registrar to send the first confirmation message, and if no response is received to that message then the gaining registrar would need to carry out confirmation. Under such an arrangement, the gaining registrar must obtain validation from the Registrant if the losing registrar has not received validation in response to the first confirmation message, and if the gaining registrar does not obtain an explicit confirmation from the registrant, then the gaining registrar must cancel the transfer operation. Registrars that operate via resellers, will often let the reseller carry out the validation process (particularly where language issues are involved), but that those registrars must still comply with the requirements to ensure that the process is being carried out in accordance with the transfers policy, and documentation must still be maintained and made available during dispute resolution The removal of the word "solely" will provide some flexibility in implementation, whilst ensuring that the gaining registrar is ultimately responsible. |
Proposed revised text: The Gaining Registrar is responsible for validating Registrant requests to transfer domain names between Registrars.
|
||
10 | Current recommendation: In the event that a Registrant has not confirmed their intent to transfer with the Losing Registrar and the Losing Registrar has not explicitly denied the transfer request in accordance with these recommendations, the default action will be that the Losing Registrar must allow the transfer to proceed. |
A longer period following the transfer to confirm a transfer - e.g 10 days instead of 5 days, would increase the chances of the losing registrar getting a positive response from the registrant, and thus reduce the number of disputes. This must be balanced against the potentially negative impact on the registrant in terms of a longer process to complete a transfer. This could be mitigated by requiring a losing registrar to immediately send a transfers approve message (as supported under both RRP and EPP protocols) to the registry when the registrant approves a transfer, and thus may offer the registrant the option to reduce 5 days down to less than 24 hours, to balance the possibly longer period if the registrant fails to respond. Before increasing the period to 10 days, a significant portion of registrars (e.g accounting for more than 66% of total registrations) would need to implement software to support immediate positive acknowledgements. Note most losing registrars only send a message to the registry when a transfer has been denied. Note under recommendations 8 and 9, if the losing registrar has not received confirmation, a gaining registrar must not allow a transfer to proceed if the registrant has not explicitly confirmed the transfer request. See also comments in recommendation 8 about the need to confirm the request via the registrant/admin contact listed in the WHOIS, rather than "verify the intent of the registrant". The text of recommendation 11 could be improved similarly. |
Suggested replacement text: In the event that a Registrant or Admin Contact listed in the WHOIS has not confirmed their request to transfer with the Losing Registrar and the Losing Registrar has not explicitly denied the transfer request in accordance with these recommendations, the default action will be that the Losing Registrar must allow the transfer to proceed. | ||
11 |
Existing Recommendation: If the Losing Registrar chooses to independently confirm the intent of the Registrant when the Losing Registrar receives notice of a pending transfer from the Registry, the Losing Registrar must do so in a manner consistent with the standards set forth in these recommendations of this report pertaining to Gaining Registrars. 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 Registrant’s decision(s) including the outcome if the Registrant doesn’t respond.
|
The intent of the suggested additional text is to ensure that a losing registrar does not attempt to unduly confuse a registrant by primarily sending marketing communications with some authorisation text buried. There have been some reports of emails from losing registrars being blocked by SPAM filters because of their high advertising content, and the lack of response from registrants has in turn created distrust by losing registrars in the process of gaining registrars. Thus it is important to ensure that losing registrars follow the same standardised text as gaining registrars for authentication messages, and that this text be sent within a time limit. Losing registrars are free to send any other additional messages before or after the authentication text. The `24-hour' time limit may need to be reviewed, especially with smaller registrars and it will undoubtedly be a factor of how long the 'transfer pending' period is. Another issue that frequently arises is the use of language. Often a losing registrar is sending communication in a language other than the native language of the registrant, and the registrant can't reply as they don't understand the authentication message. This often happens where a registrant has purchased a domain name through a reseller using their native language, and the reseller has later chosen a different registrar. The registrant then gets a message from the losing registrar in English. It is important that the standardised messages take into account different languages (e.g through a link to a common website with translations of the authentication message in different languages, or translations are provided in the original authentication message). |
Suggested additional text:
|
||
12 | The presumption in all cases will be that the Gaining Registrar has received and authenticated the requisite request from the Registrant or Administrative Contact. | Further work should be done on enforcement to ensure there is a mechanism to act quickly when a registrar is not following the transfer policy (e.g., the equivalent of some form of injunction that allows a losing registrar to deny the transfer despite lack of response from the registrant) as well as the normal dispute resolution process (that may take weeks to resolve). |
13 | Existing Recommendation: In instances where the Losing Registrar does not feel that the Gaining Registrar has obtained the requisite authorizations described in these recommendations, the Losing Registrar may file a dispute as described in the Reference Implementation | There are circumstances where a gaining registrar may wish to file a dispute in cases when a losing registrar is abusing their ability to deny a transfer. |
Additional text: Either registrar should be able to file a dispute | ||
14 | Existing recommendation: 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 (the Losing Registrar has other mechanisms available to it to collect payment from the Registrant that are independent from the Transfer process.) . |
Should be consistent with TF recommendation 24 (e). A common area of dispute is when a transfer is denied during the 45 day grace period following an auto-renew by the registry after domain name expiry. Some registrars view that because they have been automatically charged the registry fee at that point, that the registrant has an obligation to renew their name through their existing registrar. Other registrars note that a registrar can always delete a name before the end of the 45 day grace period following an auto-renewal and therefore they are only really carrying the registry charge for 45 days (ie it affects cash flow). Verisign Registry is currently considering moving from an auto-renew process, to an explicit renew process, where the domain name is still active for 45 days past expiry, but would be auto-deleted if not explicitly renewed. The general principle seems to be if a registrar can obtain a refund for the registry fee following a transfer during the 45 day grace period, than the registrar should not be able to deny the transfer for non-payment. Note there are some issues about the timing of processes where a transfer is initiated towards the end of the grace period. While mechanisms such as registrar LOCK and HOLD can be used to indirectly prevent a transfer for non-payment, it is worthwhile being explicit in this recommendation when such approaches are appropriate. |
Additional text: Except for non-payment for previous registration period if transfer is requested after the expiration date, or non-payment of the current registration period, if transfer is requested before the expiration date. | ||
15 | In EPP-based TLDs, a Losing Registrar must not refuse to release an “AuthInfo Codes” to the Registrant solely because there is a dispute between a Registrant and the Registrar over payment. | Registries that operate using the EPP protocol already have contractual conditions that require the registrar to provide the AuthInfo code upon request. There are other mechanisms such as Registrar Hold or equivalent that a losing registrar can use to deny a transfer as covered in recommendation 24. |
16 | Existing Recommendation: 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 authority of the Registrant supercedes that of the Administrative Contact. |
The suggested replacement text takes into account that EPP registries such as .biz and .info have a centrally provided WHOIS service that is defined as authoritative in the ICANN registry agreements. Note that some registrars do not update the central registry WHOIS at the time that their local information is updated, and in some cases the data between the two WHOIS services is out of synchronization. Thus the losing registrar WHOIS may have the more up-to-date information. In other cases the reliability of the central registry WHOIS is far higher than the losing Registrar Whois. The suggested replacement text allows for some flexibility in implementation for the gaining registrar. For the purposes of dispute resolution, the authoritative WHOIS will be as defined in the ICANN registry agreements (for example in the case of .com and .net, the losing registrar WHOIS is authoritative, and in the case of .biz, the registry WHOIS is authoritative (see http://www.icann.org/tlds/agreements/biz/registry-agmt-appo-11may01.htm)) |
Suggested Replacement text: The Administrative Contact and the Registrant, as outlined in the Losing Registrar’s or Registry’s (where available) publicly accessible WHOIS service are the only parties that have the authority to approve or deny a transfer request to the Gaining Registrar. In the event of a dispute, the authority of the Registrant in the authoritative Whois service supercedes that of the Administrative Contact | ||
17 | Existing Recommendation: The Gaining Registrar must use a Standardized Form of Authorization to seek the approval of the Registrant or Administrative Contact. |
A reported under 11, it is important that languages issues are taken into account in the development of the standardised messages. |
Suggested replacement text: The Gaining or Losing Registrar must use a Standardized Form of Authorization to seek the approval of the Registrant or Administrative Contact. English is the mandatory default language for all registrar, registry and registrant transfer communications. Additionally, registrars may communicate with registrants in other languages provided that the principle of standardization this principle is satisfied | ||
18 | ICANN should support the development of this Standardized Form of Authorization through staff consultation with impacted stakeholders with guidance as to intent and scope from this Task Force. This form must be useable in both physical and online automated systems (web, email). | It is critical to ensure that registrars are key contributors in the development of standardized forms. |
19 |
In the event that the Gaining Registrar must rely on a physical process to obtain this authorization, a paper copy of the Standardized 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.
|
|
20 | Existing recommendation: Gaining Registrars must maintain copies of the Standardized Form of Authorization by the Registrant or Administrative Contact of Record as per the standard document retention policies of the contracts. |
It is important that all documentation that might be used to resolve disputes be maintained by registrars, not just standardized forms. Both gaining and losing registrars will need to keep such documentation. |
Suggested replacement text: Registrars are responsible for keeping copies of documentation required for filing and supporting a dispute resolution process | ||
21 | Existing Recommendation: Gaining Registrars must allow inspection by the Losing Registrar, and other relevant third parties such as ICANN, the Registry Operator or a third party Dispute Resolution Panel, of the evidence relied upon for the transfer during and after the applicable Inter-Registrar domain name transfer transaction(s). |
This may be facilitated by extending the period available for a losing registrar to accept or reject a transfer, so that the losing registrar may check the processes of a gaining registrar. Given that some losing registrars are denying a transfer on the basis of a negative confirmation from the registrant, the gaining registrar should have the right to inspect evidence of such a response. |
Suggested Replacement text: Gaining and losing registrars must allow inspection by the matching registrar, and other relevant third parties such as ICANN, the Registry Operator or a third party Dispute Resolution Panel, of the evidence relied upon for the transfer during and after the applicable Inter-Registrar domain name transfer transaction(s). | ||
22 | Copies of the Reliable Evidence of Identity must be kept with the Standardized Form of Authorization. The Gaining Registrar must retain, and produce pursuant to a request by a Losing Registrar, a written or electronic copy of the Standardized Form of Authorization. The Losing Registrar retains the right to inspect this documentation at all times consistent with existing document retention requirements. | Minimum, standardized documentation should be required of registrars for all transfer procedure steps for use in dispute resolution. |
23 | In instances where the Losing Registrar has requested copies of the Standardized Form of Authorization, the Gaining Registrar must fulfill the Losing Registrar’s request (including providing the attendant supporting documentation) within a reasonable period of time from the receipt of the request. The Task Force recommends (3) business days. Failure to provide this documentation within the time period specified is grounds for reversal by the Registry Operator or Dispute Resolution Panel in the event that a transfer complaint is filed in accordance with the recommendations of this report. |
Losing and gaining registrars should be required to complete all specific transfer process steps within to-be-determined and specifically defined time periods. The 3 day period is implementable for infrequent requests associated with small numbers of domain names, it would become burdensome for a registrar if a losing registrar requested copies for say every transfer in the past 12 months, or sent a request for copies of documentation every day. The wording might be best expressed in the contract as "use reasonable commercial endeavours to respond within 3 days taking into account the number of domain names involved and the frequency of requests". It may be useful to standardize on an approach for time-stamping the receipt of the standardised form of authorisation, and using the domain name as a retrieval key. It is possible that some of the automated forms of authorization (email, or web based) could be stored in a database for easy retrieval at either a registrar or potentially a registry |
24 |
Existing Recommendation: A Losing Registrar may deny a transfer request only in the following instances;
|
Would be useful to clarify example of "reasonable" dispute over the identity of the Registrant or Administrative Contact. The principle should be that the gaining registrar will rely on the information available in the authoritative WHOIS. The registrant should be required to update the information in the Losing Registrar's WHOIS prior to initiating a transfer. Registrars may provide special, standardized Whois access, which may be separate from public Whois access, to other registrars and the registry solely for the purpose of transacting transfers. (note this may become necessary as part of possible privacy outcomes from future WHOIS recommendations) Registrars believe that all the acceptable reasons should be combined in one place (thus the additional text picks up some of these reasons). The registry software automatically rejects a transfer during the first 60 days of registration. Note most registry software currently automatically rejects a transfer if the domain name is in LOCK or HOLD status or equivalent. Some registrars place all their names on LOCK status by default to provide additional protection to the registrant and it is important that such registrars provide a readily accessible mechanism to turn the LOCK feature off so that they can transfer. After January 25, 2003, VGRS will be displaying the domain name status in WHOIS, so registrars will be able to check to see if a name is in lock status before proceeding with a transfer; note also that this allowable reason is consistent with TF recommendation 25c. . There are situations where domain names have been hijacked by initiating a large number of transfers through several registrars to make it difficult to trace the original registrant. There is also the issue of how to implement a transfer undo command when a transfer may keep occurring many times in quick succession. It would increase stability of the system to also put a 60 day block on a transfer to a registrar other than the original registrar after a transfer has completed. Another possible protection could be to allow a losing registrar to deny a transfer that has occurred within 60 days of a change of licence holder for a particular domain name. This could be considered using the process for adding reasons. Register.com has suggested that a fast track mechanism be established where a losing registrar may deny a transfer where they have been unable to obtain confirmation from the registrant, and there is objective evidence that a gaining registrar is not complying with the transfers policy. Possible measures that advisory about such registrar's marketing practices; There also needs to be a mechanism for updating the allowable reasons. For example it might require support by registrars representing at least 66% of the registrations by volume, as well as a resolution at the GNSO council. In cases of abuse of this recommendation, a registry may be able to remove the ability for a losing registrar to deny a transfer using the RRP or EPP protocol (Hold and lock would still be available) |
There should be a finite list of allowable reasons for denying a transfer request with the understanding that procedures should be put into place to modify the list if registrars support any changes. Upon denying a transfer request for any reason, registrars must provide the registrant and the other registrar the reason for denial |
||
25 |
Instances when the Losing Registrar may not deny a transfer include, but are not limited to;
|
Probably better to make sure that 24 is a complete list, and use 25 to clarify areas where a transfer may not be denied. |
26 |
That Registrars have access to a suitable process(es) by which they can dispute any specific transfers that they might object to after the fact (i.e. – a dispute resolution processes as outlined in the Reference Implementation described elsewhere in this report). And that such processes specifically include provisions that fulfill the following requirements;
If the gaining registrar is responsible for transfer authentication and the losing registrar’s special Whois is not accessible for a to-be-specified time; this can be grounds to allow the transfer to occur in case of a dispute. |
If a registrant wants to file a dispute, it must do so via the gaining or losing registrar. Prior to filing a transfer dispute, the filing registrar should first attempt to solve the issue with the other registrar in question through the email address noted in recommendation 3. With regard to 26 (f) the dispute resolution process only relates to whether a registrar has followed the transfer process. It cannot be used to resolve disputes between parties that both claim to be the registrant (e.g., if contact details are not maintained in the WHOIS). A registrar that files the dispute bears any costs associated with the dispute, if the other registrar has complied with the transfer process With regard to 26 (a) VGRS would prefer that a neutral 3rd party does this but it appears that it would be quite costly and therefore should be used at the appeal level only. VGRS is willing to perform this function for .com and .net transfer disputes under the condition that the revised policy provides explicit requirements that can be enforced objectively based on clearly measurable criteria. This is a recommendation that has significant cost impact on all registries so their concurrence is very important. It should be noted that using a neutral 3rd party for dispute resolution could be fairly costly. A couple of the UDRP service providers have indicated that they would consider doing this. As just one example, admittedly for a different process, WIPO's minimum charge for a UDRP dispute is $1500. More investigation of alternatives needs to be done on this. In regards to WHOIS it was noted that for com/net the losing registrar holds the authoritative WHOIS information, and the accuracy of the WHOIS information often deteriorates after transfer s due to the different data formats used by the various losing registrars. This can increase the likelihood of problems using the registrant or admin contact information to authenticate a transfer. For .biz, .info, .name and other EPP based registries, typically the registry holds the authoritative WHOIS information, and this is unaffected by a transfer. |
27 |
Existing Recommendation: That Registries implement a “Transfer Undo” command that will assist Registrants and Registrars in resetting a domain name back to its original state in the event that a transfer has occurred in contravention of the recommendations of this document. |
Registries have reported that this would be difficult to implement if transfers can keep occurring every 5 days. There would also be difficulties in managing a dispute resolution process, if transfers were occurring between multiple registrars during the dispute resolution process. It is recommended therefore that further transfers to another registrar not be allowed for 60 days (or another period established by consensus) following a transfer. This allows dispute resolution processes to be resolved, and allow a registry to reverse a transfer command. It also offers some protection for both registrants and losing registrars. The 60 day period should relate to transfers to a registrar different to the original registrar, and not restrict the ability of a registrant to choose to return to their original registrar independently of any dispute resolution process. The suggested replacement text replaces the word "command" with the word "mechanism" to allow registries some flexibility in how they implement the Transfer Undo feature. Instead of creating a new protocol command (e.g not currently covered in the proposed IETF EPP standard), registries may choose to implement the feature via a website admin tool or even a manual paper process. |
Suggested Replacement text: That Registries implement a “Transfer Undo” mechanism that will assist Registrants and Registrars in resetting a domain name back to its original state in the event that a transfer has occurred in contravention of the recommendations of this document. | ||
28 |
That the implementation and execution of these recommendations be monitored by the DNSO. Specifically that;
|
|
29 | Guidance. The Task Force has completed three supplementary documents (“Exhibit A, Reference Implementation”, “Exhibit B, Proposed Dispute Resolution Model” and “Exhibit C, Standardized Definitions”) in support of these recommendations. These exhibits are submitted as guidance to those that will be required to craft and/or implement the policies adopted as a result of these recommendations. |
[1] other submissions were received by the Task Force consisting of 4 “thank you for your submission/I agree”; 1 complaint re: pop-up ads repeated 3 times; and 1 comment intended for the Whois task force)
[2] From a Public Comment Period submission from Tim Ruiz (et al) (http://dnso.dnso.org/dnso/dnsocomments/comments-transfer/Arc01/doc00000.doc)
[3] The Task Force heard this from a number of sources, but it is most readily conveyed in the collection of Registrants comments submitted by Danny Younger. These comments can be found at http://dnso.dnso.org/dnso/dnsocomments/comments-transfer/Arc01/msg00006.html
[4] This proposal was formally submitted to the Task Force by the Registrar Constituency and formed the basis for much of the early work of the task force.
Broitman, Elana, and Ross Wm. Rader.
“Inter-Registrar Domain Name Transfers; Principles & Processes for
Gaining and Losing Registrars.” ICANN-Registrars.
[5] General Counsel’s Briefing Concerning the Implementation of Policies by Registrars and Registry Operators
[6] If you've read this far, you have the sincerest thanks of the Task Force.
[7] 3 other comments were received. One was an administrative notice from the DNSO secretariat and the other two were requests for clarification by the Task Force Chair.