Draft Transfer Task Force Implementation Report

21 January 2003

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

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); note some NEW items are added after 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

High High impact or support + Positive impact 0 No impact / easily doable

Med Medium impact or support - Negative impact * See Table 2

Low Low impact or support ? Unknown N/A Not applicable

TABLE 1
#	Description	Cost	Enf	Feas	Tech	Supp
1	Min. standards / ICANN policies	Low	Yes	Yes	Yes	High
2	Existing protocols & standards	Low	Yes	Yes	Yes	High
3	Email address for registrars & registry	Low	Yes	Yes	Yes	High
4	Clear & concise processes	Low	Yes	Yes	Yes	High
5	Registrant informed of transfer process	Low	Yes	Yes	Yes	High
6	For EPP, registrar must provide registrant unique ‘auth-info code’ within 72 hours.	Low	Yes	Yes	Yes	High
7	For EPP, ease of getting ‘auth code’ must not be any more difficult for use with transfers than for other transactions.	Low	Yes	Yes	Yes	High
8	Standardized form	Low	Yes	Yes	Yes	High
9	Gaining registrar is solely responsible for validating transfer request but losing registrar may do its own validation.	Low	Yes	Yes	Yes	Med
10	Lack of response from the registrant to the losing registrar is not an acceptable reason for denying a transfer.	N/A	Yes	Yes	Yes	Med
11	If losing registrar elects to independently validate the transfer request, it must be done consistently with transfer policy standards.	N/A	Yes	Yes	Yes	High
12	The gaining registrar will be given the benefit of doubt regarding validation of the transfer request. Losing registrar may file dispute.	N/A	Yes	Yes	N/A	Med
13	Losing registrar may file a dispute.	Med	Yes	Yes	Yes	High
14	Transfer processes must not be used as a means to secure payment.	N/A	Yes	Yes	Yes	Med
15	For EPP, the losing registrar must not refuse to issue an ‘auth code’ because of lack of payment.	N/A	Yes	Yes	Yes	Med
16	Only the Admin Contact or Registrant as listed in the losing registrar’s Whois may authorize transfers. The Registrant’s authority overrules the Admin Contact in case of a dispute.	N/A	Yes	Yes	Yes	High
17	The gaining registrar must use a standardized form to validate the transfer.	Low	Yes	Yes	Yes	High
18	ICANN should facilitate the development of the standardized form. Form must be usable in printed or electronic (email/web) format.	Low	Yes	Yes	Yes	High
19	A printed copy of the completed standardized form is acceptable if signed by the registrant or admin contact and accompanied by the applicable Whois information.	Med	Yes	Yes	Yes	High
19a	If a printed form is used, registrar is responsible for validating identity.	Med	Yes	Yes	Yes	High
19b	Acceptable forms of identity for printed forms include: notarized statement, valid driver’s license, passport, articles of incorporation, military ID, state or government issued ID, birth certificate.	Med	Yes	Yes	Yes	High
19c	In case of electronic authentication, acceptable forms of identity include electronic signature in conformance with national legislation or email address of admin contact or registrant as recorded in losing registrar’s Whois.	Low	Yes	Yes	Yes	High
20	Gaining registrars must maintain copies of the Standardized Form of Authorization.	Low	Yes	Yes	Yes	High
21	Gaining registrar must allow inspection of evidence used for verification by losing registrar, ICANN, dispute provider, registry.	N/A	Yes	Yes	Yes	High
22	Copies of the Reliable Evidence of Identity must be kept with the Standardized Form of Authorization. The losing registrar retains the right to inspect evidence at all times consistent with existing document retention requirements.	Med	Yes	Yes	Yes	High
23	The Gaining Registrar must fulfill the Losing Registrar’s request for evidence within three business days.	Med	Yes	Yes	Yes	Med
24	A Losing Registrar may deny a transfer request only in the following instances: a) evidence of fraud; b) UDRP action; c) Court order; d) reasonable dispute over the identity of the Registrant or Administrative Contact; e) No payment for previous registration period (including credit card charge-backs) if the domain name is past its expiration date or for previous or current registration periods if the domain name has not yet expired. In all such cases, however, the domain name must be put into “Registrar Hold” status by the Losing Registrar prior to the denial of transfer; f) Express written objection from the Registrant or Administrative contact. (e.g. – email, fax, paper document or other processes by which the Registrant has expressly and voluntarily objected through opt-in means).	N/A	Yes	Yes	Yes	Med
25	Instances when the Losing Registrar may not deny a transfer include, but are not limited to: a) Nonpayment for a pending or future registration period; b) No response from the Registrant or Administrative contact unless the Losing Registrar shows evidence of express written objection from the Registrant or Administrative Contact. (e.g., email, fax, paper document or other processes by which the Registrant has expressly and voluntarily objected through opt-in means); c) Domain name in Registrar Lock Status unless the Registrant is provided with the reasonable opportunity and ability to unlock the domain name prior to the Transfer Request; d) Domain name registration period time constraints other than during the first 60 days of initial registration; e) General payment defaults between Registrar and business partners / affiliates in cases where the Registrant for the domain in question has paid for the registration.	N/A	Yes	Yes	Yes	Med
26	There must be a dispute resolution process with these requirements: a) Resolution of the disputes should be administered by a third party or the pertinent Registry operator or both; b) the process must be limited in scope to issues arising out of inter-Registrar domain name transfers; c) the process must be solely initiated by a Registrar; d) appeal of rulings is allowed, but is limited in number; e) the policy must include specific obligations for all parties to the dispute to provide documentation to the dispute resolution provider; f) the Registrar filing a dispute must pay the cost of filing the dispute and the party that “loses” the dispute must pay the cost of administering the dispute resolution and reimburse the filing Registrar for the filing fees if applicable; and g) the third party dispute resolution service or Registry must 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.	Med	Yes	Yes	Yes	High
27	Registries must 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.	?	Yes	Yes	Yes, with constraints	Med
28	The implementation and execution of these recommendations should be monitored by the GNSO.	Med	N/A	Yes	N/A	Med
28a	ICANN Staff should analyze and report to the GNSO Council at three, six and twelve month intervals after implementation with the goal of determining: i) How effectively and to what extent the policies have been implemented and adopted by Registrars, Registries and Registrants; ii) Whether or not modifications to these policies should be considered by the GNSO as a result of the experiences gained during the implementation and monitoring stages; iii) The effectiveness of the dispute resolution processes and a summary of the filings that have been resolved through the process.	Med	N/A	Yes	N/A	High
28b	The GNSO Council may instruct the staff to: i) continue bi-annual reviews in a manner consistent with the aforementioned requirements; or ii) report again to the Council in an additional twelve-month time frame.	Med	N/A	Yes	N/A	High
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.	N/A	N/A	N/A	N/A	N/A

Table 2 Detailed implementation analysis
#	Current recommendation with suggested enhancements	Comments and issues
1	Registrants must be able to transfer their domain name registrations between Registrars provided that the Gaining Registrar's transfer process follows minimum standards and such transfer is not prohibited by ICANN or Registry policies..
2	Implementation of these conclusions and recommendations should, wherever possible, use existing protocols and standards.	There are two primary registry to registrar protocols in use. RRP – developed by Verisign and used for com/net/org EPP – developed within the IETF process and still being finalised. Verisign have announced that they will migrate from RRP to EPP near the end of 2003, and into 2004.
3	Existing Recommendation: Registrars must provide and maintain an email address for use by all other Registrars and registries where formal communications concerning the transfer process can be sent and dealt with by the receiving Registrar.	To facilitate timely and effective communications between registrars regarding the transfer process, a unique and private address should avoid problems that might occur when mixed with other email traffic.
3	Suggested Replacement text: Registrars should provide a unique and private email address for use only by other registrars and the registry: This email is for transfer issues only. The address should be managed to ensure messages are received by someone who can respond to the transfer issue. A timeframe should be required for responses such as this: “commercially reasonable” but not to exceed XX time period. XX time period will be determined within 3 months of implementation.
4	Inter-Registrar domain name transfer processes must be clear and concise in order to avoid confusing Registrants or other stakeholders.	A recommended first step is to prepare a list of all transfer process communications that should be standardized.
5	Current recommendation: The Registrant must be informed of and have access to, the published documentation of the specific transfer process of their current Registrar. The Task Force notes that it would also be useful for Registrants to have access to the transfer process documentation of Registrars that the Registrant is considering switching to.	The TF recommendation says, “The Registrant must be informed of . . .” It is not always possible to ensure that a registrant is informed so this part of the TF recommendation could not reasonably be implemented or enforced. The transfer process could be included in the terms and conditions of the registration agreement.
5	Suggested replacement text: Reasonable efforts should be made to inform registrant of and have access to, the published documentation of the specific transfer process of their current registrar. The Task Force notes that it would also be useful for Registrants to have access to the transfer process documentation of Registrars that the Registrant is considering switching to.
6	In EPP-based gTLD Registries, Registrars must provide the Registrant with the Registrant’s unique “AuthInfo Code” within a reasonable period of time of the Registrant’s initial request. The Task Force observes support that this reasonable time period is 72 hours or a similarly limited period of time.
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.	A recommended first step is to prepare a list of all transfer process communications that should be standardized.
9	The Gaining Registrar is solely responsible for validating Registrant requests to transfer domain names between Registrars. (a) However, this does not preclude the Losing Registrar from exercising its option to independently confirm the Registrant’s intent to transfer its domain name to the Gaining Registrar.	This is an area of some controversy amongst registrars. Some registrars have proposed that the losing registrar be the one to initially validating the registrant request, and that the gaining registrar can take over if the losing registrar fails to receive authorisation. To some extent this issue is dealt with with the EPP protocol, in that an entity requesting a transfer must have the valid AuthInfo code for the domain name, which is usually only available from the registrant or administrative contact. Also the authInfo code can only be supplied by the Losing registrar. One option is to allow some choice amongst pairs of gaining/losing registrars by agreement. A particular pair of registrars may agree that only the losing registrar should authenticate the registrant, another pair my decide that only the gaining will authenticate, and another pair may each decide to send messages to the registrants. The latter is increasingly becoming the default option. The registry could maintain a matrix of the various choices of gaining/losing registrar pairs, which would help in the development of customer service communications with the registrant. It has also been noted that registrars that operate via resellers, will often let the reseller carry out the authentication process, but that those registrars must still comply with the requirements to ensure that the process is being carried out in accordance with the transfers policy, and documentation must still be maintained and made available during dispute resolution
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.	Some registrars are not supportive of the TF recommendation that lack of response from the registrant cannot be used as a reason for denying a transfer. This is because in the past some gaining registrars have not been rigorous in obtaining authority from the registrant, and there has been no systematic auditing of the gaining registrars processes by ICANN or the Registries. Other registrars are concerned that losing registrars make little effort to obtain confirmation of a transfer, and instead concentrate on marketing to the registrant to get them to change their mind. This in turn has led to the communications from the losing registrar being either ignored or misinterpreted. The current recommendation appears to be a reasonable compromise provided there is suitable enforcement of the processes for gaining and losing registrar. It has also been suggested that a longer period following the transfer – e.g 10 days instead of 5 days, would increase the chances of the losing registrar getting a positive response from the registrant. This must be balanced against the potentially negative impact on the registrant in terms of a longer process to complete a transfer. This could be mitigated by requiring a losing registrar to immediately send a transfers approve message (as supported under both RRP and EPP protocols) to the registry when the registrant approves a transfer, and thus may offer the registrant the option to reduce 5 days down to less than 24 hours, to balance the possibly longer period if the registrant fails to respond. Before increasing the period to 10 days, a significant portion of registrars (e.g accounting for more than 66% of total registrations) would need to implement software to support immediate positive acknowledgements. Note most losing registrars only send a message to the registry when a transfer has been denied.
11	Existing Recommendation: If the Losing Registrar chooses to independently confirm the intent of the Registrant when the Losing Registrar receives notice of a pending transfer from the Registry, the Losing Registrar must do so in a manner consistent with the standards set forth in these recommendations of this report pertaining to Gaining Registrars. Specifically, the form of the request employed by the Losing Registrar must provide the Registered Name holder with clear instructions for approving or denying the request for authorization and a concise declaration describing the impact of the Registrant’s decision(s) including the outcome if the Registrant doesn’t respond. 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.	The intent of the changes is to ensure that a losing registrar does not attempt to unduly confuse a registrant by primarily sending marketing communications with some authorisation text buried. There have been some reports of emails from losing registrars being blocked by SPAM filter because of their high advertising content, and the lack of response from registrants has in turn created distrust by losing registrars in the process of gaining registrars. Thus it is important to ensure that losing registrars follow the same standardised text as gaining registrars for authentication messages, and that this text be sent within a time limit. Losing registrars are free to send any other additional messages before or after the authentication text. The `24-hour’ time limit may need to be revisited, especially with smaller registrars and it will undoubtedly be a factor of how long the ‘transfer pending’ period is. If however the period is extended to accommodate smaller registrars, the larger registrars should not be able to send marketing communications more than a time limit (say 1 hour) before the authentication message is sent out in response to the message from the registry. Another issue that frequently arises is the use of language. Often a losing registrar is sending communication in a language other than the native language of the registrant, and the registrant can’t reply as they don’t understand the authentication message. This often happens where a registrant has purchased a domain name through a reseller using their native language, and the reseller has latter chosen a different registrar. The registrant then gets an message from the losing registrar in English. It is important the standardised messages take into account different languages (e.g through a link to a common website with translations of the authentication message in different languages, or translations are provided in the original authentication message.
11	Suggested additional text: Authentication communications with registrants regarding the transfer process should not include any information other than that contained in the standardized form., Authentication communications with registrants should be sent as soon as operationally possible but must be sent not later than 24 hours.
12	The presumption in all cases will be that the Gaining Registrar has received and authenticated the requisite request from the Registrant or Administrative Contact.	Further work should be done on enforcement to ensure there is a mechanism to act quickly when a registrar is not following the transfer policy (e.g., the equivalent of some form of injunction that allows a losing registrar to deny the transfer despite lack of response from the registrant) as well as the normal dispute resolution process (that may take weeks to resolve).
13	Existing Recommendation: In instances where the Losing Registrar does not feel that the Gaining Registrar has obtained the requisite authorizations described in these recommendations, the Losing Registrar may file a dispute as described in the Reference Implementation.	There are circumstances where a gaining registrar may wish to file a dispute in cases when a losing registrar is abusing their ability to deny a transfer.
13	Additional text: Either registrar should be able to file a dispute
14	Existing recommendation: In the event of dispute(s) over payment, the Losing Registrar must not employ transfer processes as a mechanism to secure payment for services from a Registrant (the Losing Registrar has other mechanisms available to it to collect payment from the Registrant that are independent from the Transfer process.) .	Should be consistent with TF recommendation 24 (e). A common area of dispute is when a transfer is denied during the 45 day grace period following an auto-renew by the registry after domain name expiry. Some registrars view that because they have been automatically charged the registry fee at that point, that the registrant has an obligation to renew their name through their existing registrar. Other registrars note that a registrar can always delete a name before the end of the 45 day grace period following an auto-renewal and therefore they are only really carrying the registry charge for 45 days (ie it affects cash flow). Verisign Registry is currently considering moving from an auto-renew process, to an explicit renew process, where the domain name is still active for 45 days past expiry, but would be auto-deleted if not explicitly renewed. The general principle seems to be if a registrar can obtain a refund for the registry fee following a transfer during the 45 day grace period, than the registrar should not be able to deny the transfer for non-payment. Note there are some issues about the timing of processes where a transfer is initiated towards the end of the grace period.
14	Additional text: Except for non-payment for previous registration period if transfer is requested after the expiration date, or non-payment of the current registration period, if transfer is requested before the expiration date.
15	In EPP-based TLDs, a Losing Registrar must not refuse to release an “AuthInfo Codes” to the Registrant solely because there is a dispute between a Registrant and the Registrar over payment.
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	Existing Recommendation: The Gaining Registrar must use a Standardized Form of Authorization to seek the approval of the Registrant or Administrative Contact.	A recommended first step is to prepare a list of all transfer process communications that should be standardized. A reported under 11, it is important that languages issues are taken into account in the development of the standardised messages.
17	Suggested replacement text: All transfer process communications to registrants from losing and gaining registrars should be standardized. (Standardization to be determined and decided later.) English is the mandatory default language for all registrar, registry and registrant transfer communications. Additionally, registrars may communicate with registrants in other languages provided that the principle of standardization this principle is satisfied
18	ICANN should support the development of this Standardized Form of Authorization through staff consultation with impacted stakeholders with guidance as to intent and scope from this Task Force. This form must be useable in both physical and online automated systems (web, email).	Whereas it seems perfectly okay for ICANN to facilitate development of standardized forms, the most critical factor is to ensure that registrars are key contributors to the development of standardized forms.
19	In the event that the Gaining Registrar must rely on a physical process to obtain this authorization, a paper copy of the Standardized Form of Authorization will suffice insofar as it has been signed by the Registrant or Administrative Contact and is accompanied by a physical copy of the Losing Registrar’s Whois output for the domain name in question. 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. 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 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	Existing recommendation: Gaining Registrars must maintain copies of the Standardized Form of Authorization by the Registrant or Administrative Contact of Record as per the standard document retention policies of the contracts. .	It is important that all documentation that might be used to resolve disputes be maintained by registrars, not just standardized forms.
20	Suggested replacement text: Registrars are responsible for keeping copies of documentation required for filing and supporting a dispute resolution process.
21	Existing Recommendation: Gaining Registrars must allow inspection by the Losing Registrar, and other relevant third parties such as ICANN, the Registry Operator or a third party Dispute Resolution Panel, of the evidence relied upon for the transfer during and after the applicable Inter-Registrar domain name transfer transaction(s).	This may be facilitated by extending the period available for a losing registrar to accept or reject a transfer, so that the losing registrar may check the processes of a gaining registrar.
21	Suggested Replacement text: Both gaining and losing registrars should allow inspection of evidence by the other side.
22	Copies of the Reliable Evidence of Identity must be kept with the Standardized Form of Authorization. The Gaining Registrar must retain, and produce pursuant to a request by a Losing Registrar, a written or electronic copy of the Standardized Form of Authorization. The Losing Registrar retains the right to inspect this documentation at all times consistent with existing document retention requirements.	Minimum, standardized documentation should be required of registrars for all transfer procedure steps for use in dispute resolution.
23	In instances where the Losing Registrar has requested copies of the Standardized Form of Authorization, the Gaining Registrar must fulfill the Losing Registrar’s request (including providing the attendant supporting documentation) within a reasonable period of time from the receipt of the request. The Task Force recommends (3) business days. Failure to provide this documentation within the time period specified is grounds for reversal by the Registry Operator or Dispute Resolution Panel in the event that a transfer complaint is filed in accordance with the recommendations of this report.	Losing and gaining registrars should be required to complete all specific transfer process steps within to-be-determined and specifically defined time periods.
	Existing Recommendation: A Losing Registrar may deny a transfer request only in the following instances; Evidence of fraud UDRP action Court order Reasonable dispute over the identity of the Registrant or Administrative Contact No payment for previous registration period (including credit card charge-backs) if the domain name is past its expiration date or for previous or current registration periods if the domain name has not yet expired. In all such cases, however, the domain name must be put into “Registrar Hold” status by the Losing Registrar prior to the denial of transfer. 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)	Would be useful to clarify example of “reasonable” dispute over the identity of the Registrant or Administrative Contact. The principle should be that the gaining registrar will rely on the information available in the losing registrars WHOIS. The registrant should be required to update the information in the Losing Registrar’s WHOIS prior to initiating a transfer. Upon receiving any updates to Whois data elements from the Registered Name Holder, Registrar shall promptly update its database used to provide the public Whois access. Registrars may provide special, standardized Whois access, which may be separate from public Whois access, to other registrars and the registry solely for the purpose of transacting transfers. (note this may become necessary as part of possible privacy outcomes from future WHOIS recommendations) As the Special Whois is only accessible between registrars and registry and only for purposes of authenticating transfers, and as finding fair and flexible rules for defining query rate limits seems not possible, the Special Whois access must not be query rate limited and must be provided with the same treatment to all registrars. If the gaining registrar is responsible for transfer authentication and the losing registrar’s special Whois is not accessible for a to-be-specified time; this can be grounds to allow the transfer to occur in case of a dispute. Registrars believe that all the acceptable reasons should be combined in one place. Note most registry software currently automatically rejects a transfer if the domain name is in LOCK or HOLD status (set by either the registry or the registrar) in the case of the RRP registries, and if the domain name is in EPP states such as TransferProhibited or Hold status. Some registrars place all their names on LOCK status by default to provide additional protection to the registrant. And some offer this as a value added “brand protection” service. It is important that such registrars provide a readily accessible mechanism to turn the LOCK feature off so that they can transfer. If this is not made available to the registrant, then this should be grounds for dispute resolution against the losing registrar. After January 25, 2003, VGRS will be displaying the domain name status in WHOIS, so registrars will be able to check to see if a name is in lock status before proceeding with a transfer; note also that this allowable reason is consistent with TF recommendation 25c. . The registry software automatically rejects a transfer during the first 60 days of registration. There are situations where domain names have been hijacked by initiating a large number of transfers through several registrars to make it difficult to trace the original registrant. There is also the issue of how to implement a transfer undo command when a transfer may keep occurring many times in quick succession. It would increase stability of the system to also put a 60 day block on a transfer after a transfer has completed. There also needs to be a mechanism for updating the allowable reasons. For example it might require support by registrars representing at least 66% of the registrations by volume, as well as a resolution at the GNSO council.
	Additional text: - domain name is in lock status provided that the registrar provides a readily accessible and easy means for the registrant to remove the lock status. - A domain name is in the first 60 days of an initial registration period - A domain name is within 60 days (or a lessor period to be determined) of being transferred There should be a finite list of allowable reasons for denying a transfer request with the understanding that procedures should be put into place to modify the list if registrars support any changes. Upon denying a transfer request for any reason, registrars must provide the registrant and the other registrar the reason for denial
25	Instances when the Losing Registrar may not deny a transfer include, but are not limited to; Nonpayment for a pending or future registration period 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) 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. Domain name registration period time constraints other than during the first 60 days of initial registration. General payment defaults between Registrar and business partners / affiliates in cases where the Registrant for the domain in question has paid for the registration.	Probably better to make sure that 24 is a complete list, and use 25 to clarify areas where a transfer may not be denied.
26	That Registrars have access to a suitable process(es) by which they can dispute any specific transfers that they might object to after the fact (i.e. – a dispute resolution processes as outlined in the Reference Implementation described elsewhere in this report). And that such processes specifically include provisions that fulfill the following requirements; Resolution of the disputes should be administered by a third party or the pertinent Registry operator or both. That the processes be limited in scope to issues arising out of inter-Registrar domain name transfers That the processes be solely initiated by a Registrar. That appeal of rulings is allowed, but is limited in number. That the policy include specific obligations for all parties to the dispute to provide documentation to the dispute resolution provider 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. 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. If the gaining registrar is responsible for transfer authentication and the losing registrar’s special Whois is not accessible for a to-be-specified time; this can be grounds to allow the transfer to occur in case of a dispute.	If a registrant wants to file a dispute, it must do so via the gaining or losing registrar. Prior to filing a transfer dispute, the filing registrar should first attempt to solve the issue with the other registrar in question through the email address noted in recommendation 3. With regard to 26 (f) the dispute resolution process only relates to whether a registrar has followed the transfer process. It cannot be used to resolve disputes between parties that both claim to be the registrant (e.g., if contact details are not maintained in the WHOIS). A registrar that files the dispute bears any costs associated with the dispute, if the other registrar has complied with the transfer process With regard to 26 (a) VGRS would prefer that a neutral 3rd party does this but it appears that it would be quite costly and therefore should be used at the appeal level only. VGRS is willing to perform this function for .com and .net transfer disputes under the condition that the revised policy provides explicit requirements that can be enforced objectively based on clearly measurable criteria. This is a recommendation that has significant cost impact on all registries so their concurrence is very important. It should be noted that using a neutral 3^rd party for dispute resolution could be fairly costly. A couple of the UDRP service providers have indicated that they would consider doing this. As just one example, admittedly for a different process, WIPO’s minimum charge for a UDRP dispute is $1500. More investigation of alternatives needs to be done on this. Email communications can be used for dispute resolution if the registry was bcc'd on the email message. Bcc, not cc, is to be used to limit customer service emails being sent to the registry from entities other than registrars. Email communications sent in response to mail bcc'd to the registry can be used during the dispute resolution. The registrar is encouraged to forward these messages to the registry as well.
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.	Registries have reported that this would be difficult to implement if transfers can keep occurring every 5 days. It is recommended therefore that further transfers not be allowed for 60 days (or another period established by consensus) following a transfer. This allows dispute resolution processes to be resolved, and allow a registry to reverse a transfer command. It also offers some protection for both registrants and losing registrars.
28	That the implementation and execution of these recommendations be monitored by the DNSO. Specifically that; ICANN Staff analyse and report to the Names Council at three, six and twelve month intervals after implementation with the goal of determining; How effectively and to what extent the policies have been implemented and adopted by Registrars, Registries and Registrants, 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, The effectiveness of the dispute resolution processes and a summary of the filings that have been resolved through the process. Pursuant to which, the Names Council may instruct the staff to; Continue bi-annual reviews in a manner consistent with the aforementioned requirements, or; Report again to the Names Council in an additional twelve month time frame. 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.

Table Headings

Legend

Table 2 Detailed implementation analysis