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
|Table 2 Detailed implementation analysis
|Text of Task Force Recommendation & Suggested
Amendments of the Imp-Comm
|Comments and issues
|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.
|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.
|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.
|Inter-Registrar domain name transfer processes must be clear and
concise in order to avoid confusing Registrants or other stakeholders.
|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
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
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.
|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.
|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.
|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.
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.
|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.
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
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
Proposed revised text: The Gaining Registrar is responsible
for validating Registrant requests to transfer domain names between
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.
|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.
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
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.
|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.
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
- 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:
- 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 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).
|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
|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
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
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.
|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.
|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.
|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
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
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
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
|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
|Existing Recommendation: The Gaining Registrar must use a
Standardized Form of Authorization to seek the approval of the Registrant
or Administrative Contact.
A reported under 11, it is important that languages
issues are taken into account in the development of the standardised
|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
|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,
|It is critical to ensure that registrars are key contributors in
the development of standardized forms.
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
- Notarized statement
- Valid Drivers license
- 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
- 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.
|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
|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
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
|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.
|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
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
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
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
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)
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
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.
|Probably better to make sure that 24 is a complete list, and use
25 to clarify areas where a transfer may not be denied.
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
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
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
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.
|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.
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
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
b. Pursuant to which, the Names Council may instruct the staff
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
|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