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.
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.
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.
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.)
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.
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 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 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 Registry’s 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
[TOP]

Broitman, Elana. “[Registrars] Registrar transfers.” Online Posting. June 29, 2001. Registrar Constituency Mailing List. November 27, 2002 < http://www.dnso.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://www.dnso.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://www.dnso.org/clubpublic/Registrars/Arc01/msg03652.html >

Exhibit A - Reference Implementation
[TOP]

Gaining Registrar Processes

Gaining Registrar Processes Narrative

The following section is intended to act as a descriptive guide to the processes outlined in the previous.

1. Entity Files Transfer Request - The entity in question may be any of the following: the Registrant, the administrative contact, or someone authorized to act on the Registrant's behalf. This transfer request may be filed through virtually any means including telephone, email, web, etc. It is not mandatory at this point that the entity be verified as having the authority to initiate a change in SLD Sponsorship.
2. Gaining Registrar retrieves Whois record for domain from Losing Registrar and stores output - This could be accomplished through any Whois service as long as the output is an accurate representation of the Losing Registrar's data at the time of capture by the Gaining Registrar.
3. Whois Data is invalid - This covers a number of conditions including invalid or out of date email addresses or other contact information
4. Whois Data is valid - Validity is solely determined when the Gaining Registrar can reasonably conclude that the Whois data provided by the Losing Registrar is correct. (e.g. - email sent to the admin contact doesn't bounce).
5. Gaining Registrar attempts to contact the Registrant or Administrative Contact of record., for manual authorization - This can be undertaken, especially in automated environments, when the primary contact data is incorrect (e.g. - email address) but other data elements are correct (e.g. - phone number). The Gaining Registrar should use all means at their disposal to contact the Registrant or Administrative Contact of record.  If no response is available, the transfer request must not be honored and must necessarily fail.
6. The Registrant is provided with means of verification - this may take many forms including simplified web forms or paperwork. The Gaining Registrar may choose to employ a means of verification not contemplated by this document as long as the means comply with this document, specifically the minimum standards of data acquisition and retention, in written or electronic form, as outlined in 5.k. The documentation that verifies the transaction is called the "Form of Authorization" (FOA). In all cases, the FOA must provide the Registrant with clear instructions for approving or denying the request for authorization, the identity of the Gaining Registrar (and other parties to the transaction - e.g. resellers) and a concise statement describing the impact of the Registrant's decision(s). This requirement is intended to ensure that the form of request employed by the Gaining Registrar is substantially administrative and informative in nature and clearly provided to the Registrant for the purpose of verifying the intent of the Registrant.
7. Customer decides intent - This is a decision point at which the Registrant or Administrative Contact of record must determine whether or not they wish to undertake the transfer request.
8. The Registrant or Administrative Contact of record denies authorization - Gaining Registrar does not continue the transaction.
9. No response is received from the Registrant or Administrative Contact of record - Gaining Registrar does not continue the transaction. No Response is received from the Registrant or Administrative Contact of record, - Gaining Registrar does not continue with the transaction.
10. The Registrant or Administrative Contact of record verifies transfer request – Acquisition of the FOA must be undertaken in a manner that can be documented and cannot be reasonably intercepted, forged or otherwise duly influenced by third parties.
11. Transfer authorization record stored with transaction by Gaining Registrar - In addition to the minimum data acquisition and retention requirements specified by ICANN and the Registry to ensure the validity of transactions from an audit perspective, at least one of the following forms of data must be acquired and retained by the Gaining Registrar in a form that facilitates the inspection rights of the Losing Registrar;
    1. Physical: Form of Authorization signed by the Registrant or Administrative Contact of record. Such authorization must make explicit reference to the domain name(s) being transferred.  A signed master FOA separate from an electronic communication with the domain names in question is also acceptable, so long as this master FOA is physically signed by both an authorized representative of the Gaining Registrar and the Registrant or Administrative Contact of record.
    2. Electronic: A copy of the electronic communication sent to the Registrant or Administrative Contact of record, by the Gaining Registrar notifying, in reply to or confirming the initial domain name transfer request described in 5.f.  The language of the electronic communication;
       1. must make clear to the Registrant that its domain name is being transferred to the Gaining Registrar.
       2. must be stored and saved with any applicable header information (date and time sent, sender, "to" addressee, etc.).
       1. In case of an email authorization, the Gaining Registrar;
          1. must retain a copy of the email to the Registrant or Administrative Contact of record, confirming the transfer, and;
          2. must maintain log files reflecting all system transactions with respect to the above transfers, including
             1. email addresses that communications were sent to in obtaining authorization of the transfer,
             2. the dates and times (mm/dd/yyyy hh:mm:ss) reflecting when;
                1. the transfer was initially requested
                2. the Gaining Registrar requested authorization
                3. the FOA was obtained by the Gaining Registrar from the Registrant or Administrative Contact of record.
                4. the Gaining Registrar filed the transfer of SLD Sponsorship request with the Registry,
                5. a copy of the Whois information, as obtained from the Losing Registrars Whois database, for such domain name prior to the transfer for the domain name registration.
12. Transfer request sent to verification queue for inspection - An inspection queue should be used to re-verify the validity of the transfer request. See next description for full explanation.
13. Inspection (optional) - This may be a manual inspection, automated inspection or a combination of both. The purpose of this inspection is to ensure that obviously forged or suspect requests that have not been captured by previous processes are not forwarded to the Registry for action. It is recommended that Registrars implement both a manual and automated check. The automated portion should consist of a check against a blacklist of domains that must not be transferred.
14. Gaining Registrar does not approve transfer request - this can occur for any number of reasons, including suspicious transaction patterns.
15. Gaining Registrar approves transfer request - if the Gaining Registrar is satisfied with the apparent validity of the transaction, it may send the transfer request to the Registry for processing.
16. Transfer request sent to Registry - this is undertaken exclusively via the RRP or EPP between the Gaining Registrar and the Registry.
17. Registry sends transfer announcement to Losing Registrar - implementation details are typically at the sole discretion of the Registry in question. The Losing Registrar must adapt its systems and processes to the form and substance of this announcement in accordance with the minimum standards set forth in this document.
18. Losing Registrar minimum attribute check - Upon receipt of the transfer announcement sent by the Registry, the Losing Registrar may undertake to check that the domain registration is not subject to one or any of the conditions described in section 4f of this document:
19. Losing Registrar denies transfer - If the registration pending transfer possesses any, or any number of, the aforementioned attributes, the Losing Registrar may deny the transfer request in accordance with the relevant Registry Agreement.
20. Registry cancels transfer, notifies Gaining Registrar - self explanatory
21.   Losing Registrar does nothing/acknowledges transfer - if the registration pending transfer does not possess the aforementioned attributes, then the Losing Registrar must authorize the transfer request.
22. Registry undertakes transfer and notifies Gaining Registrar - self-explanatory.
23. Gaining Registrar notifies the Registrant of successful transfer - self-explanatory. May be conducted by any number of means.
24. Transfer Fails – Self-explanatory.
    

Losing Registrar Processes

Losing Registrar Process

Losing Registrar Processes Narrative

The following section is intended to act as a guide to the processes outlined in the previous diagram.

1. Registry Transfer Notification - Registry sends out notification of pending transfer to Losing Registrar.
2. Losing Registrar Receives notification makes note of "domain_name" - Losing Registrar determines which domain name is pending transfer away.
3. Losing Registrar retrieves customer contact information from local database - Losing Registrar retrieves contact and customer details related to the domain pending transfer from its own records.
4. Notifies the Registrant of pending request to transfer to another Registrar - Losing Registrar notifies the Registrant that its domain name is currently subject to a pending transfer away request.
5. Customer decides intent – The Registrant reviews pending transfer request and determines whether or not he wishes to continue with the transfer request, or whether or not the originating transfer request is valid.
6. Do nothing/No Response - The Registrant chooses not to, or does not respond to the notification of pending transfer.
7. Verify transfer request - The Registrant explicitly approves the pending transfer request as being valid.
8. Deny transfer request - The Registrant explicitly denies the pending transfer request as being valid.
9. Transfer Fails - The Losing Registrar files a non-acknowledgement of transfer request ("n'ack") with the Registry in case of 7.h by the Registrant.
10. Registry Undertakes transfer - The Registry allows the pending transfer request to continue as being a valid and approved transfer request in case of step 7.f or 7.g by the Registrant. 

Exhibit B – Proposed Dispute Resolution Model
[TOP]

This section attempts to create a process by which Registrars could seek enforcement on specific issues directly with the appropriate Registry operator and, if necessary, escalate to a “Dispute Resolution Panel” as a final measure in the case of disputes that were not clear violations of policy. Registrars are responsible for initiating these enforcement and resolution processes.

1. There are three levels to the dispute resolution process
   1. Request for enforcement
      1. A Registrar may choose to file their dispute directly with the relevant Registry Operator. This is the first level of resolution, but may be appealed to the Dispute Resolution Panel.
   2. Appeal to Third Party resolution
      1. A Registrar dissatisfied with the findings of the Registry Operator may appeal the finding to the Dispute Resolution Panel.
   3. Third party resolution
      1. A Registrar may choose to file their dispute directly with the Third Party Resolution panel, in which case, they forfeit their right to an appeal and the decision of the panel is binding.
2. The Registry Operator is responsible for resolving disputes that fall under section 1.a.i above.
   1. Disputes that fall under section 1.a.i are those that arise under the Registry/Registrar contracts.
3. Request for Enforcement Process
   1. Registrar files a Request for Enforcement with the applicable Registry Operator
   2. Registry Operator would request all applicable documentation not already received from the Gaining and Losing Registrars within three (3) Registry business days of receipt of the request.
   3. Registry would review the data in the documentation and compare such data with that contained within the authoritative Whois database.  In all cases, the authoritative Whois database is that contained in the Registry Operator’s Whois database. If the Registry Operator Whois does not provide enough information to make an informed finding, the Registry Operator will rely on the data contained in the Losing Registrar’s Whois database.
   4. If the data does not match, the Registry Operator should contact each Registrar and require additional documentation
   5. If the gaining Registrar cannot provide a complete FOA, where such data matches that contained within the authoritative Whois database, then the Registry Operator shall find that the transfer should be reversed.
   6. If the losing Registrar cannot provide evidence that on its face demonstrated any of the factors contained in Section 3(e) above, and the gaining Registrar provides to the Registry a complete FOA, which appears accurate on its face, then the transfer should be approved.
   7. If the data provided by neither Registrar appears to be either valid or conclusive on its face, then the Registry shall issue a finding of “no decision.” And refers the issue to the Dispute Resolution Panel.
   8. The request for enforcement process must complete within 14 business days of receipt of the request for enforcement by the Registry.
   9. Fees.  The gaining and losing Registrars recognize that providing this dispute resolution service may result in extra costs to the Registry Operator.  As such, the issue of appropriate fees (if any) that a Registry Operator may charge, and who is responsible for such fees (if any), shall be determined by ICANN in consultation with the gTLD Registries and Registrars. In the event that any fees are assessed for providing this service, the party that loses such dispute shall be responsible for covering the entire amount of fees. Such fees shall not be passed on to the legitimate Registrant.
4. Appeal Process
   1. Refer to dispute resolution panel/provider
5. Third Party Resolution
   1. Refer to dispute resolution panel/provider
      1. Either Registrar (Gaining or Losing) may commence a Dispute Resolution Proceeding against the other Registrar, whose specific rules or procedures should be determined by a drafting committee of the Transfer Task Force after a period of public notice and comment.  The drafting committee shall keep the following principles in mind
      2. The DRP proceeding shall be conducted by an independent neutral third party that is neither associated or affiliated with either the Losing or Gaining Registrar or the Registry Operator under which the disputed domain name is registered;
   2. Under the DRP policy, the filing Registrar (the “Complainant”) shall pay the initial filing fee (which shall be returned to the Complainant in the event that its challenge is successful).
   3. The Registry Operator, under which the disputed domain name is registered, shall provide whatever data is needed by the Dispute Resolution Panel.
   4. The sole purpose of the Dispute Resolution Panel should be to make a determination as to whether the complainants filing has merit as by current Transfer policy and determine what resolution to the complaint will appropriately redress the problem as described in the initial filing. The DRP may not deliberate disputes that fall outside of this mandate.
   5. In the event that the complaint is found to be without merit the filing Registrar shall have forfeited its initial filing fee.  In addition, if the Dispute Resolution Panel makes as specific determination that that the complaint was either frivolous or brought for the purposes of harassing the "defendant", the  Dispute Resolution Panel may impose sanctions or penalties on the filing Registrar as long as such fees are not explicitly and specifically recharged to the legitimate Registrant involved in the dispute.  Any Such sanctions or enalties that may be imposed by the Dispute Resolution Panel shall be determined in advance by the Task force an ICANN staff-led drafting committee after public notice and comment.
   6. In the event that the complaint is found to have merit, the Dispute Resolution Panel shall find in favor of the filing Registrar and shall require the following:
      1. The transfer of the domain name subject to the complaint may be returned to the appropriate Registrar at no cost to the prevailing Registrar or Registrant.
      2. The defending Registrar shall reimburse the complaining Registrar for the initial filing fee.  Failure to pay this fee to the complaining Registrar may result in the loss of accreditation by ICANN.
      3. If the Dispute Resolution Panel makes as specific determination that that the defending Registrar had no good faith basis for initiating the transfer, the Dispute Resolution Panel may impose additional sanctions or penalties on the defending Registrar as long as such fees are not explicitly and specifically recharged to the legitimate Registrant involved in the dispute. Such sanctions or penalties that may be imposed by the Dispute Resolution Panel shall be determined by the TF drafting committee after public notice and comment.

Exhibit C – Standardized Definitions

A Glossary of Terms and Acronyms

AuthInfo:  See Authorization Information Codes

Authorization Information Codes:  Authorization information is associated with domain objects to facilitate transfer operations. This information is stored as a series of codes and assigned when a domain object is created.  The codes can be updated by both Registrars and customers.  Password-based authorization is typical, but other mechanisms are allowed for by the protocols that support the transfers.

Contact: Contacts are individuals or entities associated with domain name records. Typically, third parties with specific inquiries or concerns will use contact records to determine who should act upon specific issues related to a domain name record. There are typically three of these contact types associated with a domain name record, the Administrative contact, the Billing contact and the Technical contact. 

Contact, Administrative: The administrative contact is an individual, role or organization authorized to interact with the Registry or Registrar on behalf of the Domain Holder. The administrative contact should be able to answer non-technical questions about the domain name's registration and the Domain Holder. In all cases, the Administrative Contact is viewed as the authoritative point of contact for the domain name, second only to the Domain Holder.

Contact, Billing: The billing contact is the individual, role or organization designated to receive the invoice for domain name registration and re-registration fees.

Contact, Technical: The technical contact is the individual, role or organization that is responsible for the technical operations of the delegated zone. This contact likely maintains the domain name server(s) for the domain. The technical contact should be able to answer technical questions about the domain name, the delegated zone and work with technically oriented people in other zones to solve technical problems that affect the domain name and/or zone.

DNS: See “Domain Name System”.

Domain Holder: The individual or organization that registers a specific domain name. This individual or organization holds the right to use that specific domain name for a specified period of time, provided certain conditions are met and the registration fees are paid. This person or organization is the "legal entity" bound by the terms of the relevant service agreement with the Registry operator for the TLD in question.

Domain Name System: The domain name system is a distributed database arranged hierarchically. Its purpose is to provide a layer of abstraction between other Internet services (web, email, etc .) and the numeric addresses (IP addresses) used to uniquely identify any given machine on the Internet.

EPP:  See “Extensible Provisioning Protocol”

Exclusive Registration System: A domain name registration system in which Registry services are limited to a single Registrar. Exclusive Registration Systems may be either loosely coupled (in which case the separation between Registry and Registrar systems is readily evident), or tightly coupled (in which case the separation between Registry and Registrar systems is obscure).

Extensible Provisioning Protocol: an IETF standard for Internet domain name registration between domain name Registrars and domain name registries.  This protocol provides a means of interaction between a Registrar's applications and Registry applications.  Based on a standard XML schema.

FOA: See “Standardized Form of Authorization”

GTLD: See “Top Level Domain, Generic”.

Glue Record: A Glue Record is an A record that is created as part of a delegation. 

ICANN: Internet Corporation for Assigned Names and Numbers. A non-profit organization founded to assume responsibility for IP address space assignment, protocol parameter assignment, domain name system management and root server system management.

IANA: Internet Assigned Numbers Authority. The prior organization that was tasked with responsibility for IP address space assignment, protocol parameter assignment, domain name system management and root server system management. Now limited to performing the technical delegation of TLDs under ICANN.

InterNIC: The InterNIC, a registered service mark of the U.S. Department of Commerce, is a concept for an integrated network information center that was developed by several companies, including Network Solutions, in cooperation with the U.S. Government. Until recently, the term InterNIC is being used in conjunction with a neutral, stand alone web page (located at http://www.internic.net) that has been established to provide the public with information regarding Internet domain name registration. ICANN has recently undertaken an agreement with the United States Department of Commerce to undertake operation of the effort. The InterNIC was originally created by NSF to provide specific Internet services; directory & database services (by AT&T), registration services (by Network Solutions) and information services (by General Atomics/CERFnet).

Inter-Registrar Domain Name Transfers: [ IRDX ] In a domain name transfer, the Registrant changes the service that provides the front-end domain name service.  The service provided to Registrant requires that the Gaining Registrar make a formal request to the Losing Registrar to make the Gaining Registrar the official service providing domain name service for that name.  The request that passes between the Registrars is the Inter-Registrar Domain Name Transfer.

IRDX: See inter-Registrar domain name transfers.

ISO-3166-1: A document maintained by the International Standards Organization that gives coded representations of more than 230 names of countries or areas independent from countries. This document contains two-letter (Alpha-2-code), a three-letter code (Alpha-3-code) and a three-digit numeric code (Numeric-3-code) for every entry in its list of country names. This has been typically the document that IANA uses to create ccTLD entries in the root-zone system.

NACK: See “non-acknowledgement of transfer request”

Nameserver: A computer running software that authoritatively looks up the numeric equivalent (IP Address) of a record in a zone file, usually for the purpose of allowing remote client access to remote server resources over a network. 

Namespace: All combinations of Domain Names and Top Level Domains, registered and otherwise, existing below the Root System. 

NIC: Network Information Center.

NIC Handle: A NIC Handle is an identifier in use by some Registrars and registries that is assigned to various records in the domain name database. Globally, they do not have a common format or application. Further, they are not globally unique.

Non-acknowledgement of Transfer Request [ NACK ]:  In the process on transferring a domain name, the Registrar from whom the domain is being transferred must approve or reject the transfer.  In the protocol that supports this process the request to approve or reject at transfer request must contain a message with the word “Approve” and a value of yes or no.  In the case where the transfer request is denied by the Registrar from whom the domain is being transferred, we say that the transfer request was NACKed (denied).

Object: A generic term used to describe entities that are created, updated, deleted, and otherwise managed by a generic Registry-Registrar protocol. This includes nameserver objects, contact objects and other similar entities.

Registrant: See Domain Holder.

Registrar, Accredited: A Registrar that has been certified as meeting certain minimal criteria to act as a Registrar for a specific TLD. This term is almost solely used when referring to Registrars that have been certified by ICANN. ccTLD Registries also accredit Registrars, and though they may use differing terms, the concepts are largely the same.

Registrar, Gaining: In a domain name transfer, the Registrant changes the service that provides the front-end domain name service.  The Gaining Registrar is the institution or organization that becomes the new Registrar for the Registrant.

Registrar Lock Feature: The Registrar lock feature is a feature in inter-Registrar communications that prevents unwanted Registrar transfers and DNS object changes.  The lock feature is aimed at providing Registrars with a method to prevent DNS object transfers and changes that have not been approved by the Registrant.

Registrar, Losing:  In a domain name transfer, the Registrant changes the service that provides the front-end domain name service.  The Losing Registrar is the institution or organization that used to be the Registrar and who is “losing” the service contract for registration services to the Gaining Registrar.

Registrar, Sponsoring: The Registrar responsible for the submission of the domain name to the Registry.

Registrar Operator: A term used to denote the entity providing the technical services to a Registrar in support of their registration services. Also referred to as a “Registrar Outsourcer” or “Registrar Provider”. 

Registration Authority: The policy making body for any given TLD. Examples include the Canadian Internet Registration Authority, Nominet and MuseDoma.

Registry: A Registry is the person(s) or entity(ies) responsible for providing Registry services. Registry services include customer database administration, zone file publication, DNS operation, marketing and policy determination in accordance with the general principles outlined in RFC 1591 [5]. A Registry may outsource some, all, or none of these services.

Registry, EPP-based: A Registry that uses EPP (see “Extensible Provisioning Protocol”) as the mechanism communicating with the Registrar.

Registry, RPP-based: A Registry that uses RPP (see “RPP”) as the mechanism for communicating with the Registrar.

Registry, Thick: A Registry in which all of the information associated with registered entities, including both technical information (information needed to produce zone files) and social information (information needed to implement operational, business, or legal practices), is stored within the Registry repository.

Registry, Thin: A Registry in which some element of the social information associated with registered entities is distributed between a shared Registry and the Registrars served by the Registry.

Registry Operator: Usually synonymous with the term Registry, however a Registry Operator may also be an organization or individual acting operating the Registry under an outsourced technical services management contract.

RRP: The Registry Registrar protocol:  a set of specifications for a TCP-based, 7-bit US-ASCII text protocol that permits multiple Registrars to provide second level Internet domain name registration services in the top level domains (TLDs) administered by a TLD Registry. Unlike EPP, RRP is specified using Augmented Backus-Nauer Form (ABNF)

SLD: An "SLD" is a second-level domain of the DNS

SLD, Functional: A reasonable equivalent to an SLD in a namespace where second level domains are not permitted for policy reasons. An example of a Functional SLD would be foo.com.au. While .com is the actual SLD, .au policy does not permit the widespread registration of second level domains, thereby creating a proliferation of Functional SLDs (in this case .foo) in the .au namespace.

SLD Holder: See "Domain Holder"

SLD Sponsor: See "Registrar, Sponsoring".

Shared Registration System: A domain name registration system in which Registry services are shared among multiple independent Registrars. Shared Registration Systems require a loose coupling between Registrars and a Registry.

Standardized Form of Authorization: [ FOA ] When a Gaining Registrar is in the process of executing a domain name transfer it must provide the registered domain name holder with a means of verification.  The documentation that verifies the transaction is called the "Standardized Form of Authorization" (FOA) The acronym stems from legacy applications but has been preserved for the sake of continuity and ease-of-understanding.

TLD: Top Level Domain.  A generic term used to describe both gTLDs and ccTLDs that exist under the top-level root of the domain name hierarchy.

Top Level Domain: See “TLD”.

Top Level Domain, Country Code: A TLD that corresponds to an entry in the ISO-3166-1 list. .UK, .GG, .JE are also ccTLDs despite the lack of a corresponding entry in the ISO-3166-1 list.

Top Level Domain, Generic: A TLD created to act as a globally relevant resource. Examples of these include .COM, .NET, .ORG, .INFO, .BIZ and .AERO amongst others.

Transfer Authorization Record: Gaining Registrars are required to maintain reliable evidence of express authorization by the Registrant or Administrative Contact of record.  This transfer authorization record is in a standard format and may include information from the individual or entity that has apparent authority to execute the transfer request.

Whois: a TCP transaction based query/response server, that providing netwide directory service to network users. The Whois Protocol was originally defined in RFC 954. The initial domain name related application layer implementations were centralized systems run by SRC-NIC and then later InterNIC/Network Solutions. The SRI-NIC and InterNIC implementations are more formally referred to as "NICNAME/Whois" services. Whois is not purely a domain name or IP address directory service, but has been deployed for a wide variety of uses, both public and private. Other variants of this service include RWhois and the newer Verisign Referral LDAP Whois service. Whois can refer to the protocol defined in RFC 954 or the generic application service described above.

Whois, Bulk: A data retrieval mechanism required by ICANN that specifies that all ICANN accredited Registrars must make their Whois dataset available as a single machine readable file. Put another way, Bulk Whois is the entire Registrar Whois dataset available for retrieval via FTP, HTTP or some other mechanism. Thick Registries also may provide a similar service in allowing entities to retrieve the Registry Whois dataset.

Whois, Command-line: A Whois query executed from the command line of an operating system such as Linux or MS-DOS.

Whois Record: The information or payload returned to the client as a result of a Whois query.

Whois, Referral: RWhois (Referral Whois) extends and enhances the Whois concept in a hierarchical and scaleable fashion. In accordance with this, RWhois focuses primarily on the distribution of "network objects", or the data representing Internet resources or people, and uses the inherently hierarchical nature of these network objects (domain names, Internet Protocol (IP) networks, email addresses) to more accurately discover the requested information. [6]

Whois, Registrar: Whois services made available by specific Registrars for the domain names that they sponsor at the Registry.

Whois, Registry: Whois services made available by specific registries for the domain names that they are authoritative for. Registry Whois often do not provide the comprehensive contact information that Registrar Whois services do, but they usually contain contact information for the Sponsoring Registrar. Note that the payload provided to the client by the Registry is not standardized between Registries and may vary based on the model employed by the Registry.

Whois, Web based: A World Wide Web interface to Registrar or Registry Whois services.

Zone: A portion of the total domain namespace that is represented by the data stored on a particular nameserver. The nameserver has authority over the zone – or the particular portion of the domain namespace – described by that data.  

Zone File: A file that contains data describing a portion of the domain name space. Zone files contain the information needed to resolve domain names to Internet Protocol (IP) numbers.

Exhibit D – Names Council Transfer Implementation Committee

Transfer Task Force Implementation Report - 30 January 2003

TOP]

This document provides:

• An assessment of whether a recommendation is implementable
• Information on issues that will need to be considered during implementation
• Suggested additional text to clarify or improve the existing recommendations, with the aim to obtain a net gain in the transfer process from the current situation.

Organization of the Analysis

The analysis is mostly contained in two tables. In Table 1 contains an assessment of whether the Transfers Task Force recommendation is implementable, the relative cost of implementation, and the level of support from registrars.

Table 2 contains information on issues associated with the recommendations that will need to be considered during implementation, and also where appropriate additional or alternative text to strengthen or clarify the existing recommendation.

Table Abbreviations

Table Headings

# - The number of the recommendation made by the GNSO Transfer Task Force (1-29)
Cost - What is the cost impact if the recommendation is implemented? (high/medium/low/?)
Enf - Is the recommendation enforceable if it is implemented? (yes/no/?)
Feas - Can the recommendation reasonably be implemented from a process point of view? (yes/no/?)
Supp - What is the anticipated level of support for the recommendation from registrars? (high/medium/low/?)
Tech - Can the recommendation be reasonably implemented from a technical point of view? (yes/no/?)

Legend

N/A - Not applicable

Exhibit E - End Notes