Final Report and Recommendations of the GNSO Council's Transfers Task Force
Policies and Processes for Gaining and Losing Registrars

30 November 2002
As updated 12 February 2003

Final Report and Recommendations of the GNSO Council's Transfers Task Force
Policies and Processes for Gaining and Losing Registrars
12 February 2003

Contents

Executive Summary

Policy Recommendations of the Task Force

Preamble

Consensus Policy Recommendations

Supporting Arguments

Impact, Cost, and Risk Analysis

Impact to Registrants

Impact to Registrars

Impact to gTLD Registries

General Risk and Cost Analysis

Constituency Impact (CI) Reviews

Detailed Implementation Analysis and Task Force Comments

Other Observations & Considerations

Terms of Reference

Background

Record of Outreach

I. Conference Calls & Meetings Open to Non-Task Force Participants

II. Public and Constituency Comments Received by the Task Force

Minority Reports

Historical Proposals

Exhibit A: Reference Application

Exhibit B: Proposed Dispute Resolution Model

Exhibit C: Standardized Definitions

Exhibit D: Transfers Implementation Task Force Report

Exhibit E: End Notes

Version and Revision Information

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: Impact, Cost and Risk Analysis Constituency Impact (CI) Reviews II. Public and Constituency Comments received by the Task Force

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

[Note to 12 February 2003 version: 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 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.

a. This email is for transfer issues only.

b. The address should be managed to ensure messages are received by someone who can respond to the transfer issue.

c. A timeframe should be required for responses such as this: "commercially reasonable" but not to exceed XX time period.

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

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

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

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

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

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

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

c. 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;

a. Evidence of fraud

b. UDRP action

c. Court order

d. Reasonable dispute over the identity of the Registrant or Administrative Contact

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

f. 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)

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.

A domain name is in the first 60 days of an initial registration period.

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:

a. Nonpayment for a pending or future registration period

b. No response from the Registrant or Administrative contact unless the Losing Registrar shows evidence of 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)

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

d. Domain name registration period time constraints other than during the first 60 days of initial registration.

e. 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;

a. Resolution of the disputes should be administered by a third party or the pertinent Registry operator or both.

b. That the processes be limited in scope to issues arising out of inter-Registrar domain name transfers

c. That the processes be solely initiated by a Registrar.

d. That appeal of rulings is allowed, but is limited in number.

e. That the policy include specific obligations for all parties to the dispute to provide documentation to the dispute resolution provider

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

g. 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;

a. ICANN Staff analyse and report to the Names Council at three, six and twelve month intervals after implementation with the goal of determining;

i. How effectively and to what extent the policies have been implemented and adopted by Registrars, Registries and Registrants,

ii. 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,

iii. The effectiveness of the dispute resolution processes and a summary of the filings that have been resolved through the process.

b. Pursuant to which, the Names Council may instruct the staff to;

i. Continue bi-annual reviews in a manner consistent with the aforementioned requirements, or;

ii. Report again to the Names Council in an additional twelve month time frame.

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

Impact, Cost, and Risk Analysis

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

[Note: The implementation Task Force's comments are addressed immediately below].

Detailed Implementation Analysis and Task Force Comments

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:

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

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://gnso.icann.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://gnso.icann.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://gnso.icann.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://gnso.icann.org/dnso/dnsocomments/comments-transfer/Arc01/msg00009.html)

• comments re: EPP operational models

5. From Danny Younger (http://gnso.icann.org/dnso/dnsocomments/comments-transfer/Arc01/msg00011.html)

• a summary of duties imposed by the policy

6. From Danny Younger (http://gnso.icann.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://gnso.icann.org/dnso/dnsocomments/comments-transfer/Arc02/)

Substantive Comments include:

1. From Elana Broitman (http://gnso.icann.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://gnso.icann.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://gnso.icann.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://gnso.icann.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://gnso.icann.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://gnso.icann.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 set forth enough clarity to provide Registrants, Registrars and registries with the necessary level of confidence. Shouldn’t the Task Force deal with the issue of setting clear definition for all aspects of the transfer process?"

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.

3. "Although it was raised numerous times, the Task Force does not make any specific recommendations concerning the issue of 'Apparent Authority' as it currently exists under the present policy. How does this report deal with those issues?"

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.

4. "Some parties like to 'create their own policies' and we always therefore seem to end up with a system that can be easily gamed. How does this report deal with this issue?"

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.

5. "How can 'third parties' authenticate transfers under these recommendations?"

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.

6. "Sometimes resellers and ISPs represent the Registrant. Without the notion of 'Apparent Authority' it will be impossible for these parties to authenticate a transfer. How is this addressed in these recommendations?"

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.

7. "Non-providers need to participate in the policy development process. How did the task force address the requirements of 'users' (i.e. – Registrants) during the formulation of these recommendations?"

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.

8. "Even when the best policies are adhered to in the strictest manner by all participants, sometimes things go wrong. With domain names, this might mean that a Registrant is left without the use of their domain name for a period of time. Under the current policy, this often means that Registrants have to hope for the best and put their fate in the hands of a Registrar who may  or may not cooperate when it comes to 'making things right'. Does this report deal with this dynamic in a meaningful way?"

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.

9. "Some Registrars liberally employ the 'Registrar lock' function as it relates to the domain names they register for Registrants. This often means that Registrant’s *can’t* transfer their domain name in a predictable way. Do the Task Force recommendations consider this?"

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.

10. "Shouldn't the documentation procured by the Gaining Registrar be subject to some higher standard due to the influence they have over the system? If the documents that they obtained were notarized or otherwise authenticated, the process would be much more secure for Registrants."

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.

11. "How closely did the Task Force follow the discussions that took place in various forums throughout the DNSO and the rest of the community?"

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.

12. "Doesn't 'auto-ack' simply encourage fraudulent activity to occur?"

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.

13. "Why don't these recommendations also address how to protect Registrants from unscrupulous marketing practices?"

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 U.S. the State Attorney General, or the Federal Trade Commission. In other countries, similar authorities exist. The Task Force did not address nor consider that the area of marketing practices are within the scope of the Task Force.

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.

14. "Fraudulent transfers pose a far greater problem than does 'Registrar gaming' of the current policies. Why weren’t fraudulent transfers more explicitly dealt with?"

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.

15. "Major Registrars are auto-n'acking and they report that this has substantially reduced fraudulent transfers. Wouldn’t allowing the losing Registrar to 'auto-n'ack' have achieved the desired results? What’s wrong with the current policy?"

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.

16. "The current proposal creates an incentive for gaining Registrars to obtain the customer's "apparent authority" by more avenues, possibly including deceptive marketing practices, since it will allow for transfers without verification of the Registrant's objective manifestation of intent to transfer.  How does the proposal address the situation where 'apparent authority' is obtained by fraud or deceptive marketing?"

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.

17. "This proposal is based on old thinking by the Registrar Constituency which no longer has the support of the community. Shouldn’t the Task Force allow for more time to explore alternatives?"

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.

18. "Won't implementing these changes require significant alteration to the existing contracts? Should impacted parties have an opportunity to amend or negotiate these provisions before they are included in a contract?"

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.

19. "Won't implementing these changes require Registries and Registrars to undertake significant changes to their systems and therefore incur significant costs that Registrants would ultimately be forced to bear?"

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:

• The technical or economic costs that may arise from the implications of these recommendations would not be unreasonable.
• Any implementation of these recommendations would not create any excessive or undue burden for any impacted party.

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.

Historical Proposals

Broitman, Elana. "[Registrars] Registrar transfers." Online Posting. June 29, 2001. Registrar Constituency Mailing List. November 27, 2002 <http://gnso.icann.org/clubpublic/Registrars/Arc01/msg00776.html>

Cochetti, Roger. "Letter from Roger Cochetti to Stuart Lynn." ICANN. July 16, 2001. Verisign, Inc. November 27, 2002. <http://www.icann.org/correspondence/cochetti-to-lynn-16jul01.htm>

Rader, Ross. "Inter-Registrar Domain Name Transfers Process Description & Overview." Proposal for Standardized Inter-Registrar Domain Transfers. August 26, 2001. Tucows Inc. November 27, 2002. <http://www.byte.org/rc-transfers/>

Broitman, Elana, and Ross Wm. Rader. "Inter-Registrar Domain Name Transfers; Principles & Processes for Gaining and Losing Registrars." ICANN-Registrars. October 1, 2001. ICANN DNSO Registrar Constituency. November 27, 2002. <http://www.icann-Registrars.org/pdfs/rc-irdx-091801-v1r0d8.PDF>

Gomes, Chuck, and Elliot Noss. "Mediated Authorization". DNSO Registrar Constituency Mailing List Archives. November 6, 2002. Verisign, Inc. & Tucows Inc. November 27, 2002 <http://gnso.icann.org/clubpublic/Registrars/Arc01/doc00128.doc >

Gomes, Chuck et al. "[Registrars] Fw: Principles." Online Posting. November 27, 2002. Registrar Constituency Mailing List. November 27, 2002  <http://gnso.icann.org/clubpublic/Registrars/Arc01/msg03652.html>

Exhibits

Exhibit A: Reference Application

Exhibit B: Proposed Dispute Resolution Model

Exhibit C: Standardized Definitions

Exhibit D: Transfers Implementation Task Force Report

Exhibit E: End Notes

Page Updated 17-Dec-2007
©2003 The Internet Corporation for Assigned Names and Numbers. All rights reserved.