Transfers Implementation Committee Report 30 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, 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

Table 1
#	Cost	Enf	Feas	Tech	Supp
1	Low	Yes	Yes	Yes	High
2	Low	Yes	Yes	Yes	High
3	Low	Yes	Yes	Yes	High
4	Low	Yes	Yes	Yes	High
5	Low	Yes	Yes	Yes	High
6	Low	Yes	Yes	Yes	High
7	Low	Yes	Yes	Yes	High
8	Low	Yes	Yes	Yes	High
9	Low	Yes	Yes	Yes	Med
10	N/A	Yes	Yes	Yes	Med
11	N/A	Yes	Yes	Yes	High
12	N/A	Yes	Yes	N/A	Med
13	Med	Yes	Yes	Yes	High
14	N/A	Yes	Yes	Yes	Med
15	N/A	Yes	Yes	Yes	Med
16	N/A	Yes	Yes	Yes	High
17	Low	Yes	Yes	Yes	High
18	Low	Yes	Yes	Yes	High
19	Med	Yes	Yes	Yes	High
19a	Med	Yes	Yes	Yes	High
19b	Med	Yes	Yes	Yes	High
19c	Low	Yes	Yes	Yes	High
20	Low	Yes	Yes	Yes	High
21	N/A	Yes	Yes	Yes	High
22	Low	Yes	Yes	Yes	High
23	Med	Yes	Yes	Yes	Med
24	N/A	Yes	Yes	Yes	Med
25	N/A	Yes	Yes	Yes	Med
26	Med	Yes	Yes	Yes	High
27	Med	Yes	Yes	Yes, with constraints	Med
28	Med	N/A	Yes	N/A	Med
28a	Med	N/A	Yes	N/A	High
28b	Med	N/A	Yes	N/A	High
29	N/A	N/A	N/A	N/A	N/A

Table 2 Detailed implementation analysis
#	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..	The Registry operators and ICANN should consider methods for improving the testing of a registrar’s transfer processes to ensure that their implementation is in compliance with the transfer policy. This testing could be done at the time of initial accreditation, or as part of an audit process.
2	Implementation of these conclusions and recommendations should, wherever possible, use existing protocols and standards.	There are two primary registry to registrar protocols in use. RRP – developed by Verisign and used for com/net/org 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. Where system changes (which could include software, legal or business process changes) are required at either the registry or registrars, a reasonable period of time (e.g 3 months) would be required to reach full compliance. Verisign notes that in some cases, software changes may take up to 6 months from an initial high level idea to include time to complete detailed specifications, software development, testing and deployment.

3	Existing Recommendation: Registrars must provide and maintain an email address for use by all other Registrars and registries where formal communications concerning the transfer process can be sent and dealt with by the receiving Registrar.	To facilitate timely and effective communications between registrars regarding the transfer process, a unique and private address should avoid problems that might occur when mixed with other email traffic.
	Suggested Replacement text: Registrars should provide a unique and private email address for use only by other registrars and the registry: 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. 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.

5	Current recommendation: The Registrant must be informed of and have access to, the published documentation of the specific transfer process of their current Registrar. The Task Force notes that it would also be useful for Registrants to have access to the transfer process documentation of Registrars that the Registrant is considering switching to.	The TF recommendation says, “The Registrant must be informed of . . .” It is not always possible to ensure that a registrant is informed so this part of the TF recommendation could not reasonably be implemented or enforced. The transfer process could be included in the terms and conditions of the registration agreement. Information to registrants (and registrars) may be improved by ICANN providing a central registry of the transfer processes for each registrar to ensure that each registrar had a documented process. This may consist of links to the relevant transfers policy listed on the registrar website. Some registrars are adding additional constraints to when transfers can occur into their terms and conditions. A registrar should not be able to add conditions in addition to those listed in recommendation 24, that may limit competition and attempt to lock in the consumer to a particular provider.
	Suggested replacement text: Reasonable efforts should be made to inform registrant of and have access to, the published documentation of the specific transfer process of their current registrar. The Task Force notes that it would also be useful for Registrants to have access to the transfer process documentation of Registrars that the Registrant is considering switching to.
6	In EPP-based gTLD Registries, Registrars must provide the Registrant with the Registrant’s unique “AuthInfo Code” within a reasonable period of time of the Registrant’s initial request. The Task Force observes support that this reasonable time period is 72 hours or a similarly limited period of time.	Many registrars have not properly implemented the EPP Protocol which incorporates an AuthInfo password for each domain name. To initiate a transfer a registrant must supply the AuthInfo password to the gaining registrar. The issue is that many registrars have not implemented procedures to allow a registrant to easily obtain the AuthInfo password associated with the domain name. The protocol allows for the user to select their own AuthInfo password, but the common implementation involves registrars creating this AuthInfo password on behalf of the registrant, and only provided the password to the registrant on request. It would be useful for registrars to settle on a common approach for retrieving the AuthInfo password, so that gaining registrars may instruct a registrant on the procedure to follow to retrieve the AuthInfo password. In any case the procedure for obtaining the AuthInfo password should be incorporated in the documentation for the transfer process discussed in recommendation 5.
7	In EPP-based gTLD Registries, Registrars may not employ any mechanism for a Registrant to obtain its AuthInfo Code that is more restrictive than what they require from a Registrant to change any aspect of its contact or nameserver information.
8	Current recommendation: The Gaining Registrar must verify the intention of the Registrant or Administrative Contact of Record to transfer their domain name registration by requiring that the Registrant complete a valid Standardized Form of Authorization. Suggested replacement text: The Gaining Registrar must confirm a transfer request, by requiring that the Registrant or Administrative Contact of Record as listed in the WHOIS complete a valid Standardized Form of Authorization. A transfer must not be allowed to proceed if no confirmation is received.	The current wording uses “verify the intention of the Registrant”. This may be difficult to implement legally. The replacement text uses the word “confirm”, to indicate that the registrant/admin contact listed in the WHOIS should explicitly confirm the request. In most cases a registrars’ only contact with the registrant is via a website, where the registrant has provided their contact details. There is no other information available to identify the registrant (ie no finger prints, or company incorporation documents etc) to verify the intention of the registrant. Many registrars for security reasons also do not retain credit card information. The last sentence makes it explicit that a transfer must not be allowed to proceed if no confirmation has been received.
9	Existing Recommendation: 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. Proposed revised text: The Gaining Registrar is 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.	From a customer service point of view, it would be useful for the gaining registrar to know in advance that a losing registrar will also independently confirm the Registrar’s intent. One possible implementation would be for the registry to maintain a table showing for each gaining/losing registrar pair, whether the losing registrar will independently confirm the Registrant’s intent. Given that many registrants will receive two confirmation messages (first from the gaining and then from the losing), a further customer service improvement could be achieved by cooperating pairs of registrars to allow a losing registrar to send the first confirmation message, and if no response is received to that message then the gaining registrar would need to carry out confirmation. Under such an arrangement, the gaining registrar must obtain validation from the Registrant if the losing registrar has not received validation in response to the first confirmation message, and if the gaining registrar does not obtain an explicit confirmation from the registrant, then the gaining registrar must cancel the transfer operation. Registrars that operate via resellers, will often let the reseller carry out the validation process (particularly where language issues are involved), but that those registrars must still comply with the requirements to ensure that the process is being carried out in accordance with the transfers policy, and documentation must still be maintained and made available during dispute resolution The removal of the word “solely” will provide some flexibility in implementation, whilst ensuring that the gaining registrar is ultimately responsible.
10	Current recommendation: In the event that a Registrant has not confirmed their intent to transfer with the Losing Registrar and the Losing Registrar has not explicitly denied the transfer request in accordance with these recommendations, the default action will be that the Losing Registrar must allow the transfer to proceed. Suggested replacement text: In the event that a Registrant or Admin Contact listed in the WHOIS has not confirmed their request to transfer with the Losing Registrar and the Losing Registrar has not explicitly denied the transfer request in accordance with these recommendations, the default action will be that the Losing Registrar must allow the transfer to proceed.	A longer period following the transfer to confirm a transfer – e.g 10 days instead of 5 days, would increase the chances of the losing registrar getting a positive response from the registrant, and thus reduce the number of disputes. This must be balanced against the potentially negative impact on the registrant in terms of a longer process to complete a transfer. This could be mitigated by requiring a losing registrar to immediately send a transfers approve message (as supported under both RRP and EPP protocols) to the registry when the registrant approves a transfer, and thus may offer the registrant the option to reduce 5 days down to less than 24 hours, to balance the possibly longer period if the registrant fails to respond. Before increasing the period to 10 days, a significant portion of registrars (e.g accounting for more than 66% of total registrations) would need to implement software to support immediate positive acknowledgements. Note most losing registrars only send a message to the registry when a transfer has been denied. Note under recommendations 8 and 9, if the losing registrar has not received confirmation, a gaining registrar must not allow a transfer to proceed if the registrant has not explicitly confirmed the transfer request. See also comments in recommendation 8 about the need to confirm the request via the registrant/admin contact listed in the WHOIS, rather than “verify the intent of the registrant”. The text of recommendation 11 could be improved similarly.
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. a. This requirement is not intended to preclude the Losing Registrar from marketing to its existing customers through separate communications. This requirement is intended to ensure that the form of the request employed by the Losing Registrar is substantially administrative and informative in nature and clearly provided to the Registrant for the purpose of verifying the intent of the Registrant. 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 after receiving the transfer request.	The intent of the suggested additional text is to ensure that a losing registrar does not attempt to unduly confuse a registrant by primarily sending marketing communications with some authorisation text buried. There have been some reports of emails from losing registrars being blocked by SPAM filters because of their high advertising content, and the lack of response from registrants has in turn created distrust by losing registrars in the process of gaining registrars. Thus it is important to ensure that losing registrars follow the same standardised text as gaining registrars for authentication messages, and that this text be sent within a time limit. Losing registrars are free to send any other additional messages before or after the authentication text. The `24-hour’ time limit may need to be reviewed, especially with smaller registrars and it will undoubtedly be a factor of how long the ‘transfer pending’ period is. Another issue that frequently arises is the use of language. Often a losing registrar is sending communication in a language other than the native language of the registrant, and the registrant can’t reply as they don’t understand the authentication message. This often happens where a registrant has purchased a domain name through a reseller using their native language, and the reseller has later chosen a different registrar. The registrant then gets a message from the losing registrar in English. It is important that the standardised messages take into account different languages (e.g through a link to a common website with translations of the authentication message in different languages, or translations are provided in the original authentication message).
12	The presumption in all cases will be that the Gaining Registrar has received and authenticated the requisite request from the Registrant or Administrative Contact.	Further work should be done on enforcement to ensure there is a mechanism to act quickly when a registrar is not following the transfer policy (e.g., the equivalent of some form of injunction that allows a losing registrar to deny the transfer despite lack of response from the registrant) as well as the normal dispute resolution process (that may take weeks to resolve).
13	Existing Recommendation: In instances where the Losing Registrar does not feel that the Gaining Registrar has obtained the requisite authorizations described in these recommendations, the Losing Registrar may file a dispute as described in the Reference Implementation.	There are circumstances where a gaining registrar may wish to file a dispute in cases when a losing registrar is abusing their ability to deny a transfer.
	Additional text: Either registrar should be able to file a dispute
14	Existing recommendation: In the event of dispute(s) over payment, the Losing Registrar must not employ transfer processes as a mechanism to secure payment for services from a Registrant (the Losing Registrar has other mechanisms available to it to collect payment from the Registrant that are independent from the Transfer process.) . 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.	Should be consistent with TF recommendation 24 (e). A common area of dispute is when a transfer is denied during the 45 day grace period following an auto-renew by the registry after domain name expiry. Some registrars view that because they have been automatically charged the registry fee at that point, that the registrant has an obligation to renew their name through their existing registrar. Other registrars note that a registrar can always delete a name before the end of the 45 day grace period following an auto-renewal and therefore they are only really carrying the registry charge for 45 days (ie it affects cash flow). Verisign Registry is currently considering moving from an auto-renew process, to an explicit renew process, where the domain name is still active for 45 days past expiry, but would be auto-deleted if not explicitly renewed. The general principle seems to be if a registrar can obtain a refund for the registry fee following a transfer during the 45 day grace period, than the registrar should not be able to deny the transfer for non-payment. Note there are some issues about the timing of processes where a transfer is initiated towards the end of the grace period. While mechanisms such as registrar LOCK and HOLD can be used to indirectly prevent a transfer for non-payment, it is worthwhile being explicit in this recommendation when such approaches are appropriate.
15	In EPP-based TLDs, a Losing Registrar must not refuse to release an “AuthInfo Codes” to the Registrant solely because there is a dispute between a Registrant and the Registrar over payment.	Registries that operate using the EPP protocol already have contractual conditions that require the registrar to provide the AuthInfo code upon request. There are other mechanisms such as Registrar Hold or equivalent that a losing registrar can use to deny a transfer as covered in recommendation 24.
16	Existing Recommendation: The Administrative Contact and the Registrant, as outlined in the Losing Registrar’s publicly accessible Whois service are the only parties that have the authority to approve or deny a transfer request to the Gaining Registrar. In all cases, the authority of the Registrant supercedes that of the Administrative Contact. Suggested Replacement text: The Administrative Contact and the Registrant, as outlined in the Losing Registrar’s or Registry’s (where available) publicly accessible WHOIS service are the only parties that have the authority to approve or deny a transfer request to the Gaining Registrar. In the event of a dispute, the authority of the Registrant in the authoritative WHOIS service supercedes that of the Administrative Contact.	The suggested replacement text takes into account that EPP registries such as .biz and .info have a centrally provided WHOIS service that is defined as authoritative in the ICANN registry agreements. Note that some registrars do not update the central registry WHOIS at the time that their local information is updated, and in some cases the data between the two WHOIS services is out of synchronization. Thus the losing registrar WHOIS may have the more up-to-date information. In other cases the reliability of the central registry WHOIS is far higher than the losing Registrar Whois. The suggested replacement text allows for some flexibility in implementation for the gaining registrar. For the purposes of dispute resolution, the authoritative WHOIS will be as defined in the ICANN registry agreements (for example in the case of .com and .net, the losing registrar WHOIS is authoritative, and in the case of .biz, the registry WHOIS is authoritative (see http://www.icann.org/tlds/agreements/biz/registry-agmt-appo-11may01.htm))
17	Existing Recommendation: The Gaining Registrar must use a Standardized Form of Authorization to seek the approval of the Registrant or Administrative Contact. Suggested replacement text: The Gaining or Losing Registrar must use a Standardized Form of Authorization to seek the approval of the Registrant or Administrative Contact. English is the mandatory default language for all registrar, registry and registrant transfer communications. Additionally, registrars may communicate with registrants in other languages provided that the principle of standardization this principle is satisfied	A reported under 11, it is important that languages issues are taken into account in the development of the standardised messages.
18	ICANN should support the development of this Standardized Form of Authorization through staff consultation with impacted stakeholders with guidance as to intent and scope from this Task Force. This form must be useable in both physical and online automated systems (web, email).	It is critical to ensure that registrars are key contributors in the development of standardized forms.
19	In the event that the Gaining Registrar must rely on a physical process to obtain this authorization, a paper copy of the Standardized Form of Authorization will suffice insofar as it has been signed by the Registrant or Administrative Contact and is accompanied by a physical copy of the Losing Registrar’s Whois output for the domain name in question. a. If the gaining Registrar relies on a physical authorization process, they assume the burden of obtaining Reliable Evidence of Identity of the Registrant or Administrative Contact and that the entity making the request is indeed authorized to do so. b. The Task Force notes support for the concept that recommended forms of identity that constitute Reliable Evidence of Authority include: § Notarized statement § Valid Drivers license § Passport § Article of Incorporation § Military ID § State/Government issued ID § Birth Certificate c. The Task Force notes support for the concept that in the event of an electronic authorization process, recommended forms of identity would include; § electronic signature in conformance with national legislation, for instance, the United States e-Sign Act § Email address matching Registrant or Administrative Contact email address found in authoritative Whois database.
20	Existing recommendation: Gaining Registrars must maintain copies of the Standardized Form of Authorization by the Registrant or Administrative Contact of Record as per the standard document retention policies of the contracts. .	It is important that all documentation that might be used to resolve disputes be maintained by registrars, not just standardized forms. Both gaining and losing registrars will need to keep such documentation.
	Suggested replacement text: Registrars are responsible for keeping copies of documentation required for filing and supporting a dispute resolution process.
21	Existing Recommendation: Gaining Registrars must allow inspection by the Losing Registrar, and other relevant third parties such as ICANN, the Registry Operator or a third party Dispute Resolution Panel, of the evidence relied upon for the transfer during and after the applicable Inter-Registrar domain name transfer transaction(s).	This may be facilitated by extending the period available for a losing registrar to accept or reject a transfer, so that the losing registrar may check the processes of a gaining registrar. Given that some losing registrars are denying a transfer on the basis of a negative confirmation from the registrant, the gaining registrar should have the right to inspect evidence of such a response.
	Suggested Replacement text: Gaining and losing registrars must allow inspection by the matching registrar, and other relevant third parties such as ICANN, the Registry Operator or a third party Dispute Resolution Panel, of the evidence relied upon for the transfer during and after the applicable Inter-Registrar domain name transfer transaction(s).
22	Copies of the Reliable Evidence of Identity must be kept with the Standardized Form of Authorization. The Gaining Registrar must retain, and produce pursuant to a request by a Losing Registrar, a written or electronic copy of the Standardized Form of Authorization. The Losing Registrar retains the right to inspect this documentation at all times consistent with existing document retention requirements.	Minimum, standardized documentation should be required of registrars for all transfer procedure steps for use in dispute resolution.
23	In instances where the Losing Registrar has requested copies of the Standardized Form of Authorization, the Gaining Registrar must fulfill the Losing Registrar’s request (including providing the attendant supporting documentation) within a reasonable period of time from the receipt of the request. The Task Force recommends (3) business days. Failure to provide this documentation within the time period specified is grounds for reversal by the Registry Operator or Dispute Resolution Panel in the event that a transfer complaint is filed in accordance with the recommendations of this report.	Losing and gaining registrars should be required to complete all specific transfer process steps within to-be-determined and specifically defined time periods. The 3 day period is implementable for infrequent requests associated with small numbers of domain names, it would become burdensome for a registrar if a losing registrar requested copies for say every transfer in the past 12 months, or sent a request for copies of documentation every day. The wording might be best expressed in the contract as “use reasonable commercial endeavours to respond within 3 days taking into account the number of domain names involved and the frequency of requests”. It may be useful to standardize on an approach for time-stamping the receipt of the standardised form of authorisation, and using the domain name as a retrieval key. It is possible that some of the automated forms of authorization (email, or web based) could be stored in a database for easy retrieval at either a registrar or potentially a registry
24	Existing Recommendation: A Losing Registrar may deny a transfer request only in the following instances; 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) 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 (apart from a transfer back to the original registrar) 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	Would be useful to clarify example of “reasonable” dispute over the identity of the Registrant or Administrative Contact. The principle should be that the gaining registrar will rely on the information available in the authoritative WHOIS. The registrant should be required to update the information in the Losing Registrar’s WHOIS prior to initiating a transfer. Registrars may provide special, standardized Whois access, which may be separate from public Whois access, to other registrars and the registry solely for the purpose of transacting transfers. (note this may become necessary as part of possible privacy outcomes from future WHOIS recommendations) Registrars believe that all the acceptable reasons should be combined in one place (thus the additional text picks up some of these reasons). The registry software automatically rejects a transfer during the first 60 days of registration. Note most registry software currently automatically rejects a transfer if the domain name is in LOCK or HOLD status or equivalent. Some registrars place all their names on LOCK status by default to provide additional protection to the registrant and it is important that such registrars provide a readily accessible mechanism to turn the LOCK feature off so that they can transfer. After January 25, 2003, VGRS will be displaying the domain name status in WHOIS, so registrars will be able to check to see if a name is in lock status before proceeding with a transfer; note also that this allowable reason is consistent with TF recommendation 25c. . There are situations where domain names have been hijacked by initiating a large number of transfers through several registrars to make it difficult to trace the original registrant. There is also the issue of how to implement a transfer undo command when a transfer may keep occurring many times in quick succession. It would increase stability of the system to also put a 60 day block on a transfer to a registrar other than the original registrar after a transfer has completed. Another possible protection could be to allow a losing registrar to deny a transfer that has occurred within 60 days of a change of licence holder for a particular domain name. This could be considered using the process for adding reasons. Register.com has suggested that a fast track mechanism be established where a losing registrar may deny a transfer where they have been unable to obtain confirmation from the registrant, and there is objective evidence that a gaining registrar is not complying with the transfers policy. Possible measures that advisory about such registrar's marketing practices; There also needs to be a mechanism for updating the allowable reasons. For example it might require support by registrars representing at least 66% of the registrations by volume, as well as a resolution at the GNSO council. In cases of abuse of this recommendation, a registry may be able to remove the ability for a losing registrar to deny a transfer using the RRP or EPP protocol (Hold and lock would still be available)
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. (egg – 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.	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; a. Resolution of the disputes should be administered by a third party or the pertinent Registry operator or both. b. That the processes be limited in scope to issues arising out of inter-Registrar domain name transfers c. That the processes be solely initiated by a Registrar. d. That appeal of rulings is allowed, but is limited in number. e. That the policy include specific obligations for all parties to the dispute to provide documentation to the dispute resolution provider f. That the Registrar filing a dispute pay the cost of filing the dispute, that the party that “loses” the dispute pay the cost of administering the dispute resolution and reimburse the filing Registrar for the filing fees if applicable. g. That the third party dispute resolution service or Registry be able to direct the appropriate Registry or Registrar to return a domain name to whatever state the dispute resolution provider deems appropriate based on the facts presented during the proceeding. 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. In regards to WHOIS it was noted that for com/net the losing registrar holds the authoritative WHOIS information, and the accuracy of the WHOIS information often deteriorates after transfer s due to the different data formats used by the various losing registrars. This can increase the likelihood of problems using the registrant or admin contact information to authenticate a transfer. For .biz, .info, .name and other EPP based registries, typically the registry holds the authoritative WHOIS information, and this is unaffected by a transfer.
27	Existing Recommendation: That Registries implement a “Transfer Undo” command that will assist Registrants and Registrars in resetting a domain name back to its original state in the event that a transfer has occurred in contravention of the recommendations of this document. Suggested Replacement text: That Registries implement a “Transfer Undo” mechanism that will assist Registrants and Registrars in resetting a domain name back to its original state in the event that a transfer has occurred in contravention of the recommendations of this document.	Registries have reported that this would be difficult to implement if transfers can keep occurring every 5 days. There would also be difficulties in managing a dispute resolution process, if transfers were occurring between multiple registrars during the dispute resolution process. It is recommended therefore that further transfers to another registrar not be allowed for 60 days (or another period established by consensus) following a transfer. This allows dispute resolution processes to be resolved, and allow a registry to reverse a transfer command. It also offers some protection for both registrants and losing registrars. The 60 day period should relate to transfers to a registrar different to the original registrar, and not restrict the ability of a registrant to choose to return to their original registrar independently of any dispute resolution process. The suggested replacement text replaces the word “command” with the word “mechanism” to allow registries some flexibility in how they implement the Transfer Undo feature. Instead of creating a new protocol command (e.g not currently covered in the proposed IETF EPP standard), registries may choose to implement the feature via a website admin tool or even a manual paper process.
28	That the implementation and execution of these recommendations be monitored by the DNSO. Specifically that; a. ICANN Staff analyse and report to the Names Council at three, six and twelve month intervals after implementation with the goal of determining; i. How effectively and to what extent the policies have been implemented and adopted by Registrars, Registries and Registrants, ii. Whether or not modifications to these policies should be considered by the DNSO as a result of the experiences gained during the implementation and monitoring stages, iii. The effectiveness of the dispute resolution processes and a summary of the filings that have been resolved through the process. b. Pursuant to which, the Names Council may instruct the staff to; i. Continue bi-annual reviews in a manner consistent with the aforementioned requirements, or; ii. Report again to the Names Council in an additional twelve month time frame. c. The purpose of these monitoring and reporting requirements are to allow the Names Council to determine when, if ever, these recommendations and any ensuing policy require additional clarification or attention based on the results of the reports prepared by ICANN Staff.
29	Guidance. The Task Force has completed three supplementary documents (“Exhibit A, Reference Implementation”, “Exhibit B, Proposed Dispute Resolution Model” and “Exhibit C, Standardized Definitions”) in support of these recommendations. These exhibits are submitted as guidance to those that will be required to craft and/or implement the policies adopted as a result of these recommendations.