ICANN DNSO Transfers Task Force Final Report & Recommendations

Policies and Processes for Gaining and Losing Registrars

Executive Summary

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,

November 30, 2002

Policy Recommendations of the Task Force

Preamble

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.

Consensus Policy Recommendations

[TOP]

[Note:Based on the Implementation Committee analysis and recommendations, some wording improvements resulting from the implementation committee report have been incorporated to improve the clarity and hence ease of implementation of the recommendations. "The Detailed Implementation Analysis and Task Force Comments" is also incorporated in full in this Report. For ease of identification, these changes have been tracked throughout this portion of the document. Stricken text appears in a strikethrough, and revised text and additions appear italicized. No policy changes were made in the document. Stricken text appears in a strikethrough font and amendments and additions appear italicized. No policy changes were made in the document.]

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.
2. Implementation of these conclusions and recommendations should, wherever possible, use existing protocols and standards.
3. Registrars must should provide and maintain an unique and private email address for use only by all other Registrars and the rRegistriesy: where formal communications concerning the transfer process can be sent and dealt with by the receiving Registrar.
   1. This email is for transfer issues only.
   2. The address should be managed to ensure messages are received by someone who can respond to the transfer issue.
   3. A timeframe should be required for responses such as this: “commercially reasonable” but not to exceed XX time period.
   4. XX time period will be be established and agreed upon during the implementation process, prior to the implementation of these recommendations..
4. Inter-Registrar domain name transfer processes must be clear and concise in order to avoid confusing Registrants or other stakeholders.
5. 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. 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. 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.
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. 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 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. The Gaining Registrar is solely responsible for validating Registrant requests to transfer domain names between Registrars.
   1. However, this does not preclude the Losing Registrar from exercising its option to independently confirm the Registrant’s intent to transfer its domain name to the Gaining Registrar.
10. 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. 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. 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.
    1. This requirement is not intended to preclude the Losing Registrar from marketing to its existing customers through separate communications. This requirement is intended to ensure that the form of the request employed by the Losing Registrar is substantially administrative and informative in nature and clearly provided to the Registrant for the purpose of verifying the intent of the Registrant.
    2. 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.
    3. 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.
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.
13. 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. Either registrar should be able to file a dispute.
14. 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.) 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 a dispute between a Registrant and the Registrar over payment.
16. 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 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. The Gaining Registrar must use a Standardized Form of Authorization to seek the approval of the Registrant or Administrative Contact. 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. Additionally, Registrars may communicate with registrants in other languages provided that this 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 (paper form, fax version, etc.) and online automated systems (web, email, etc.).
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.
    1. If the gaining Registrar relies on a physical authorization process, they assume the burden of obtaining Reliable Evidence of Identity of the Registrant or Administrative Contact and that the entity making the request is indeed authorized to do so.
    2. The Task Force notes support for the concept that recommended forms of identity that constitute Reliable Evidence of Authority include:
       • Notarized statement
       • Valid Drivers license
       • Passport
       • Article of Incorporation
       • Military ID
       • State/Government issued ID
       • Birth Certificate
    3. The Task Force notes support for the concept that in the event of an electronic authorization process, recommended forms of identity would include;
       
       • electronic signature in conformance with national legislation, for instance, the United States e-Sign Act
       • Email address matching Registrant or Administrative Contact email address found in authoritative Whois database.
20. 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. 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. Each Registrar is responsible for keeping copies of documentation that may be required for filing and supporting a dispute resolution process.
21. 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). Both 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).
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.
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.
24. A Losing Registrar may deny transfer requests only in specific instances and that 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 changes to the list, and that such changes be approved by ICANN staff, or another equally appropriate body, and that in the event that the changes requested constitute new policy, or are not otherwise authorized by ICANN staff or the appropriate body, that the matter be referred to the GNSO Names Council for consideration. Further that, upon denying a transfer request for any reason, registrars must provide the registrant and the other registrar the reason for denial. Therefore, a A Losing Registrar may deny a transfer request only in the following instances;
    1. Evidence of fraud
    2. UDRP action
    3. Court order
    4. Reasonable dispute over the identity of the Registrant or Administrative Contact
    5. No payment for previous registration period (including credit card charge-backs) if the domain name is past its expiration date or for previous or current registration periods if the domain name has not yet expired. In all such cases, however, the domain name must be put into “Registrar Hold” status by the Losing Registrar prior to the denial of transfer.
    6. Express written objection from the Registrant or Administrative contact. (e.g. – email, fax, paper document or other processes by which the Registrant has expressly and voluntarily objected through opt-in means)
    7. domain name is in lock status provided that the registrar provides a readily accessible and easy means for the registrant to remove the lock status.
    8. A domain name is in the first 60 days of an initial registration period
    9. A domain name is within 60 days (or a lesser period to be determined) after being transferred (apart from a transfer back to the original registrar).
25. Instances when the Losing Registrar may not deny a transfer include, but are not limited to;
    1. Nonpayment for a pending or future registration period
    2. No response from the Registrant or Administrative contact unless the Losing Registrar shows evidence of express written objection from the Registrant or Administrative Contact. (egg – email, fax, paper document or other processes by which the Registrant has expressly and voluntarily objected through opt-in means)
    3. Domain name in Registrar Lock Status unless the Registrant is provided with the reasonable opportunity and ability to unlock the domain name prior to the Transfer Request.
    4. Domain name registration period time constraints other than during the first 60 days of initial registration.
    5. General payment defaults between Registrar and business partners / affiliates in cases where the Registrant for the domain in question has paid for the registration.
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;
    1. Resolution of the disputes should be administered by a third party or the pertinent Registry operator or both.
    2. That the processes be limited in scope to issues arising out of inter-Registrar domain name transfers
    3. That the processes be solely initiated by a Registrar.
    4. That appeal of rulings is allowed, but is limited in number.
    5. That the policy include specific obligations for all parties to the dispute to provide documentation to the dispute resolution provider
    6. That the Registrar filing a dispute pay the cost of filing the dispute, that the party that “loses” the dispute pay the cost of administering the dispute resolution and reimburse the filing Registrar for the filing fees if applicable.
    7. That the third party dispute resolution service or Registry be able to direct the appropriate Registry or Registrar to return a domain name to whatever state the dispute resolution provider deems appropriate based on the facts presented during the proceeding.
27. That Registries implement a “Transfer Undo” command 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;
    1. ICANN Staff analyse and report to the Names Council at three, six and twelve month intervals after implementation with the goal of determining;
       1. How effectively and to what extent the policies have been implemented and adopted by Registrars, Registries and Registrants,
       2. Whether or not modifications to these policies should be considered by the DNSO as a result of the experiences gained during the implementation and monitoring stages,
       3. The effectiveness of the dispute resolution processes and a summary of the filings that have been resolved through the process.
    2. Pursuant to which, the Names Council may instruct the staff to;
       1. Continue bi-annual reviews in a manner consistent with the aforementioned requirements, or;
       2. Report again to the Names Council in an additional twelve month time frame.
    3. The purpose of these monitoring and reporting requirements are to allow the Names Council to determine when, if ever, these recommendations and any ensuing policy require additional clarification or attention based on the results of the reports prepared by ICANN Staff.
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.

Supporting Arguments

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;

• security
• transparency
• stability
• portability

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.

Impacted, Cost and Risk Analyses

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.

Impact to Registrants

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.

Impact to Registrars

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.

Impact to gTLD Registries

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

General Risk and Cost Analysis

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.

Constituency Impact (CI) Reviews

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;

Detailed Implementation Analysis and Task Force Comments

Other Observations & Considerations

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.

1. Registrars must not employ transfer processes that conflict with ICANN or Registry contracts. If a conflict occurs, ICANN or Registry contracts take precedent. Registrars (and their agents) may not place additional restrictions upon a Registrant in the form of a service contract in a manner contrary to ICANN or Registry policy and/or contract with respect to inter-Registrar domain name transfer transactions.
2. Inter-Registrar domain name transfers should be conducted in a manner that engenders Registrant confidence
3. Registrants, Registrars and Registries stressed the importance of an inter-Registrar transfer process that enhances the security, stability, transparency and portability found in the current policies.
4. Registrars should take into account the legal, linguistic and cultural differences of the domain name registration market, Registrars, and Registrants when implementing inter-Registrar domain name transfer processes.
5.  Registrars and Registries should not develop inter-Registrar transfer processes that place undue burden on the Registrant, Registrar or Registry.
6. Where possible, Registrars and Registries are encouraged to automate inter-Registrar domain name transfer processes as much as possible.
7. Inter-Registrar domain name transfer policies and processes adopted by Registries and Registrars should allow Registries and Registrars as much flexibility as possible in determining the scale, scope and technologies used with their own specific implementations in pursuit of their specific business models.
8. Where possible, Registrars should only initiate Inter-Registrar domain name transfers at the request of the Registrant or Administrative Contact of record.(is this duplicative)
9. It is recommended that the Losing Registrar use the EPP or RRP command set equivalent of “Registrar Hold” prior to receiving a transfer notification from the Registry as a mechanism to secure payment from a Registrant in the event of non-payment. The Losing Registrar should not use the EPP or RRP command set equivalent of “Registrar Lock” for this same purpose.
10. Inter-Registrar transfers should be conducted in a secure as possible manner and not allow for undue influence or manipulation by the losing Registrar or any other third party.

Terms of Reference

The purpose of the Task Force on Transfers is to:

• develop broad understanding across the Names Council of the issues underlying the disputed area of transfers of domain names between Registrars
• ensure  understanding of the proposed approach as documented in the Registrars’ procedural document, which has been voted on by the Registrar
• identify any broad policy issues (separate from contract issues), which are the responsibility of the DNSO
• Devise recommendations which have broad cross constituency support to any identified problems arising from the language of the existing agreements where policy needs to guide contractual changes.
• Undertake a “fast track” working effort, via a Task Force, to present a proposal for NC consideration at Marina Del Ray NC meeting and to recommend next steps, if any.

Background

In early 2001, complaints began to surface from a number of Registrars regarding denials of requested transfers, including substantial delays and confusing responses. May 25, 2001, Verisign Registrar contacted the other Registrars that it was taking specific actions to address this situation and announced a policy which seems to be in conflict with the default policy outlined in Appendix B of the Verisign-Registrar Accreditation Agreement.  On July 16, 2001, Verisign Corporate advised Stuart Lynn, President, ICANN, that they had adopted a default non acknowledgement (n’ack) policy in order to protect their customers from unauthorized transfers.  On August 27, 2001, Stuart Lynn replied to the Registrar Constituency recommending that a new policy be created to deal with the problem. Louis Touton, General Counsel and Secretary, ICANN, replied to the Verisign request, indicating that Registrars may not deny transfer requests that the gaining Registrar has verified simply because the losing Registrar has not verified it.

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:

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 Montevideo in fall, 2001, it became apparent that the other constituencies were not full aware of the situation, or the proposed solution under development by the Registrars.  A briefing was held by three constituencies (IPC, ISPCP, BC) with the Registrars Constituency representative.  It became apparent that the other constituencies believe that their members (users/Registrants) are being affected by this situation and some questioned whether there are policy as well as contract issues.   It is also clear that while the protocol is a first step, additional areas of work were needed. This has been acknowledged by the Registrar Constituency.

The issue was brought to the attention of the Names Council on an ensuing conference call (October 11, 2001) and a “fast track Task Force created.

Record of Outreach
[TOP]

I.                   Conference Calls & Meetings open to non-task force participants

II.                Public and Constituency Comments received by the Task Force

Public Comments on Task Force Interim Report, October 16 - 30, 2002
(http://www.dnso.org/dnso/dnsocomments/comments-transfer/Arc01/)

Substantive comments include:

1. General Counsel’s Briefing Concerning the Implementation of Policies by Registrars and Registry Operators (http://www.icann.org/legal/briefing-on-implementation-20oct02.htm)
   • Specific guidance to the Task Force in developing policies that can be implemented under ICANN's agreements, so that the goals the policies are intended to promote can be achieved.
2. From Tim Ruiz (et al) (http://dnso.dnso.org/dnso/dnsocomments/comments-transfer/Arc01/doc00000.doc)
   • fraudulent transfers are more of a problem than recognized
   • proposal doesn’t protect from deceptive marketing
   • auto-ack plays into fraudulently obtained apparent authority
   • needs to be another Registrar constituency vote
   • significant changes necessary to agreements
   • significant changes to Registrar/Registry systems
3. From Danny Younger (http://dnso.dnso.org/dnso/dnsocomments/comments-transfer/Arc01/msg00006.html)
   • A synopsis of various consumer complaints concerning transfers including:
     • Registrars employing an “auto-n’ack” policy
     • confusing emails attempting to authenticate Registrant wishes
     • improper rejection of transfer requests by losing Registrars
     • arduous processes imposed by losing Registrars
     • poor customer support
     • unclear and inconsistent rules regarding when a domain name may be transferred
     • deceptive or confusing marketing practices designed to retain customers
     • foreign language issues
     • inaccurate Whois data complicating the transfer process
     • inability to update Whois data
     • “apparent authority” not properly defined
     • unpaid status should not affect ability to transfer
     • procedures should be uniform for all Registrars
     • Registrars and their resellers should communicate policies better
     • Registrar failure to release auth codes
     • inappropriate use of the Registrar Lock feature
     • unauthorized transfers / “domain hijacking”
     • transfer-away charges by losing Registrars
     • failure to address complaints / poor contract enforcement
4. From Scott Hollenbeck (http://dnso.dnso.org/dnso/dnsocomments/comments-transfer/Arc01/msg00009.html)
   • comments re: EPP operational models
5. From Danny Younger (http://dnso.dnso.org/dnso/dnsocomments/comments-transfer/Arc01/msg00011.html)
   • a summary of duties imposed by the policy
6. From Danny Younger (http://dnso.dnso.org/dnso/dnsocomments/comments-transfer/Arc01/msg00013.html)
   • Description of the Names Council Rules of Procedure, and how the Interim Report doesn’t follow same.

(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/)

Substantive Comments Include:

1. From Elana Broitman (http://www.dnso.org/dnso/dnsocomments/comments-transfer/Arc02/msg00001.html)
   • questions concerning what constitutes a "Constituency Impact Statements" and the inability of the Registrar Constituency to create and provide one within the eight days allotted.
2. From Danny Younger (http://www.dnso.org/dnso/dnsocomments/comments-transfer/Arc02/msg00002.html)
   • Comments concerning the perceived deficiencies of the process followed by the Task Force and the data and analysis presented in the Final Report of the Task Force.
3. From Danny Younger (http://www.dnso.org/dnso/dnsocomments/comments-transfer/Arc02/msg00003.html )
   • concerned with the limited time during which the Final Report was available for comment.
4. From Jeff Williams (http://www.dnso.org/dnso/dnsocomments/comments-transfer/Arc02/msg00004.html)
   • concurs with Broitman's assessment (above)
   • concurs with Youngers criticism (above)
   • concerned with the lack of contact information in the Final Report
   • concerned with the lack of choice and lack of diversity that ICANN's accreditation regime creates.
5. From the Registry Constituency (http://www.dnso.org/dnso/dnsocomments/comments-transfer/Arc02/msg00005.html)
   • requests formally that no action be taken on the Final Report at the December 14, 2002 Names Council meeting;
     • too little time to for the Internet community to analyse and respond to,
     • Final Report has sparked community discussion that needs to be taken into account.
     • Registry Constituency supports many of the recommendations of the Final Report, but is reserving adopting a final position until such time that the issue has been worked out in other Constituencies, including the Registrar Constituency.
   • Proposes deferring the issue for action until the January, 2003 Names Council meeting.
6. From Chuck Gomes (http://www.dnso.org/dnso/dnsocomments/comments-transfer/Arc02/msg00007.html)
   • presents a list of sixteen principles that have been formally endorsed by ten ICANN Accredited Registrars.
   • Notes the critical nature of Registrar support for the proposed policies and encourages other Registrars that also support the document to also provide a formal indication of support.

Minority Reports

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.

1. "It appears that the Task Force only addressed the considerations raised by one proposal that was put forward by the community and not others that have been presented. Doesn’t the Task Force have a requirement to deal with all substantive proposals put forward by the community?"

   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.

2. "The policy recommendations that you have put forth don’t seem to adequately se