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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Suggested additional text:

2. Authentication communications with registrants regarding the transfer process should not include any information other than that contained in the standardized form.,
3. 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.

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.

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

A reported under 11, it is important that languages issues are taken into account in the development of the standardised messages.

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.

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.

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.

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

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)

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)

Additional text:

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

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

i. A domain name is within 60 days (or a lesser 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

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.

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.

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

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.

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.

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.