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.
Current Status: Tucows deploys a “Gaining Registrar transfer
process” which closely adheres to “Consensus Policy Recommendations Exhibit A –
Reference Implementation”.
As features of the reference implementation are
explored in the following recommendations, the details of the Tucows process
will be discussed in the appropriate recommendation section.
2. Implementation
of these conclusions and recommendations should, wherever possible, use
existing protocols and standards.
Current Status: Tucows currently deploys existing protocols
and standards. The required changes
listed in the items below do not use non-existing protocols and standards.
Required
Changes: none
Impact: none
3. 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.
Current Status:
Tucows has provided the following contact information at
http://www.internic.net/contact.html
TUCOWS.com, Inc.
96 Mowat Avenue
Toronto Ontario
M6K 3M1
Canada
(416) 535-0123
Contact: info@opensrs.org (Ross Wm. Rader)
In addition, the
email address: transfers@opensrs.org is used for email correspondence
regarding active transfer requests with the registrant. Inquiries on the status of a particular
transfer maybe sent to this email address.
Required
Changes: none
Impact: none
4. Inter-Registrar
domain name transfer processes must be clear and concise in order to avoid
confusing Registrants or other stakeholders.
Current Status: Tucows deploys a “Gaining Registrar transfer
process” which closely adheres to “Consensus Policy Recommendations Exhibit A –
Reference Implementation”. If this is
deemed clear and concise, than the Tucows process is also clear and concise.
Unfortunately, a secure transfer approach regardless
of how well structured does confuse Registrants. I cannot claim that we do not confuse Registrants, only that we
have streamlined the process as greatly as possible without comprising the
required security.
Required
Changes: none
Impact: none
5. The
Registrant must be informed of and have access to, the published
documentation of the specific transfer process of their current Registrar. The
Task Force notes that it would also be useful for Registrants to have access to
the transfer process documentation of Registrars that the Registrant is
considering switching to.
Current Status: The registrant can currently request
information regarding the Tucows transfer to and transfer away processes, and
this information will be provided.
However, this information is not proactively provided.
Required
Changes: Tucows has many web-sites specifically dedicated to
Registrants. Documentation regarding
Tucows transfer to and transfer away processes should be added to these sites.
Impact: low
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.
Current
Status: A registrant
can obtain their EPP “AuthInfo Code” at any time by accessing http://manage.opensrs.org with the
appropriate domain name, username and password. The registrant (or the admin contact) supplies the username and
password when the domain is initially ordered.
If
the registrant (or admin contact) does not remember the username/password
information, they may request this information be emailed to registrant (or
admin contact) email address.
The Tucows OpenSRS system
allows Tucows staff and resellers to send the required data to the registrant
(or admin contact) without viewing the secure username/password.
Tucows
requires that its resellers are responsive to their customers and respond to
valid customer requests within 1 business week.
Required
Changes: none
Impact:
none
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.
Current
Status: Tucows most
restrictive change mechanism occurs when the registrant (and admin contact)
email address is no longer functioning and must be changed. When this occurs, Tucows requires that the
registrant (or admin contact) provide detailed information about the individual
or organization in written format prior to implementing the change.
As
access to the EPP “AuthInfo Code” is only dependant on a valid registrant (or
admin contact) email address, the EPP “AuthInfo Code” access mechanism is not
more restrictive than other changes to the contact or nameserver information.
Required
Changes: none
Impact:
none
8. The Gaining Registrar must verify the intention of the
Registrant or Administrative Contact of Record to transfer their domain name
registration by requiring that the Registrant complete a valid Standardized
Form of Authorization.
Current
Status: When Tucows
receives a transfer to request via our order processing system:
-
The Tucows system automatically obtains a copy of the
domain whois
-
If the whois does not contain a valid email address
for the admin contact, the order is flagged for manual intervention. If a staff member of the “Tucows Transfer
team” can obtain the correct email address for the admin contact by performing
additional whois inquiries, the valid whois information will be stored and the
transfer order processing will continue.
Otherwise, the transfer request will be aborted.
-
If the whois does contain a valid email address for
the admin contact, the Tucows system will:
o
send an email to the admin contact containing:
§
instructions to go to a security web site to confirm
or deny the transfer (“transfer web site”)
§
a unique login/password combination for logging into
the “transfer web site”
o
store the:
§
admin email address, and
§
timestamp when the email was sent
-
If the admin contact:
o
does not go to the web site within 7 days, the Tucows
system will abort the transfer request
o
goes to the web site and denies the transfer, the Tucows system will:
§
store the:
·
IP address used to access the web site
·
Phone number supplied by the admin contact
·
Timestamp when the denial occurred
§
abort the transfer request
o
goes to the web site and approves the transfer, the
Tucows system will:
§
store the:
·
IP address used to access the web site
·
Phone number supplied by the admin contact
·
Timestamp when the denial occurred
§
proceed in the transfer request
Required
Changes: The “transfer web site” presented to the admin
contact does not reference the “Form of Authorization”. Although all the information required for
the Form of Authorization is collected, this information is not provided or
displayed to admin contact as a “receipt”.
Minor changes to the “transfer web site” can be implemented so that the
registrant is validating the “Standardized Form of Authorization”.
Impact:
low
9. The
Gaining Registrar is solely responsible for validating Registrant requests to
transfer domain names between Registrars.
a. However,
this does not preclude the Losing Registrar from exercising its option to
independently confirm the Registrant’s intent to transfer its domain name to
the Gaining Registrar.
See recommendation #8.
10. In
the event that a Registrant has not confirmed their intent to transfer with the
Losing Registrar and the Losing Registrar has not explicitly denied the
transfer request in accordance with these recommendations, the default action
will be that the Losing Registrar must allow the transfer to proceed.
Current Status: When Tucows receives a transfer away from
the registry:
-
The Tucows system:
o
sends an
email to the admin contact containing:
§
instructions to go to a security web site to confirm
or deny the transfer (“transfer away web site”)
§
a unique login/password combination for logging into
the “transfer away web site”
o
stores the:
§
admin email address, and
§
timestamp when the email was sent.
-
If the admin contact:
o
goes to the web site and denies the transfer, the Tucows system will:
§
store the:
·
IP address used to access the web site
·
Phone number supplied by the admin contact
·
Timestamp when the denial occurred
§
files a n’ack with the registry
o
goes to the web site and approves the transfer, the
Tucows system will:
§
store the:
·
IP address used to access the web site
·
Phone number supplied by the admin contact
·
Timestamp when the denial occurred
§
allow the transfer to proceed
o
does not go to the web site within 5 days, the Tucows
system will allow the transfer to proceed
Required
Changes: none
Impact:
none
11. If
the Losing Registrar chooses to independently confirm the intent of the
Registrant when the Losing Registrar receives notice of a pending transfer from
the Registry, the Losing Registrar must do so in a manner consistent with the
standards set forth in these recommendations of this report pertaining to
Gaining Registrars. Specifically, the form of the request employed by the
Losing Registrar must provide the Registered Name holder with clear
instructions for approving or denying the request for authorization and a
concise declaration describing the impact of the Registrant’s decision(s)
including the outcome if the Registrant doesn’t respond.
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.
Current
Status: See
recommendation #10.
Required Changes: The
“transfer away web site” presented to the admin contact does not reference the
“Form of Authorization”. Although all
the information required for the Form of Authorization is collected, this
information is not provided or displayed to admin contact as a “receipt”. Minor changes to the “transfer away web
site” can be implemented so that the registrant is validating the “Standardized
Form of Authorization”.
Impact: low
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.
See
recommendation #8.
13. In
instances where the Losing Registrar does not feel that the Gaining Registrar
has obtained the requisite authorizations described in these recommendations,
the Losing Registrar may file a dispute as described in the Reference
Implementation.
Current
Status: Tucows
currently contacts the registry regarding transfer disputes.
Required
Changes: none
Impact:
none
14. In
the event of dispute(s) over payment, the Losing Registrar must not employ
transfer processes as a mechanism to secure payment for services from a
Registrant (the Losing Registrar has other mechanisms available to it to
collect payment from the Registrant that are independent from the Transfer
process.)
Current
Status: Tucows uses “registrant hold” for securing
payment. This does not affect the
transfer process.
Required
Changes: none
Impact:
none
15. In
EPP-based TLDs, a Losing Registrar must not refuse to release an “AuthInfo
Codes” to the Registrant solely because there a dispute between a Registrant
and the Registrar over payment.
Current
Status: Tucows does
not refuse to release an “AuthInfo Codes” to a registrant solely because there
is a dispute over payment.
Required
Changes: none
Impact:
none
16. The
Administrative Contact and the Registrant, as outlined in the Losing
Registrar’s publicly accessible Whois service are the only parties that have
the authority to approve or deny a transfer request to the Gaining Registrar.
In all cases, the authority of the Registrant supercedes that of the
Administrative Contact.
Current
Status: Tucows emails the admin contact regarding the
transfer. However, if the registrant
contacts Tucows to indicate that the administrative contact is not acting as
per their wishes, and provides appropriate identity information (photo id,
articles of incorporation etc.), Tucows will stop or reverse the transfer.
Required
Changes: none
Impact:
none
17. The
Gaining Registrar must use a Standardized Form of Authorization to seek the
approval of the Registrant or Administrative Contact.
See
recommendation #8.
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).
N/A
– ICANN directive.
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.
Current
Status: Tucows
deploys an electronic authorization process using email address matching with
the Administrative Contact email address found in the authoritative Whois
Database.
Required
Changes: none
Impact:
none
20. Gaining
Registrars must maintain copies of the Standardized Form of Authorization by
the Registrant or Administrative Contact of Record as per the standard document
retention policies of the contracts.
Current Status: Tucows
electronically stores for each transfer and the required retention period:
§
timestamp of transfer request
§
admin email address
§
timestamp when confirmation email was sent to the
admin contact
§
IP address used to access the “transfer web site”
§
phone number supplied by the admin contact
§
timestamp when the admin contact approved or rejected
the transfer
Required
Changes: This stored
data can be used to produce the “Form of Authorization”.
Impact:
low
21. Gaining
Registrars must allow inspection by the Losing Registrar, and other relevant
third parties such as ICANN, the Registry Operator or a third party Dispute
Resolution Panel, of the evidence relied upon for the transfer during and after
the applicable Inter-Registrar domain name transfer transaction(s).
Current
Status: Tucows does
provide to the Losing Registrar, and other relevant third parties such as
ICANN, the Registry Operator or a third party Dispute Resolution Panel, the
evidence relied upon for the transfer during and after the applicable
Inter-Registrar domain name transfer transaction(s).
Required
Changes: none
Impact:
none
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.
Current Status: Tucows
electronically stores for each transfer and the required retention period:
§
timestamp of transfer request
§
admin email address
§
timestamp when confirmation email was sent to the
admin contact
§
IP address used to access the “transfer web site”
§
phone number supplied by the admin contact
§
timestamp when the admin contact approved or rejected
the transfer
(See
recommendation #21 re “The Losing Registrar retains the right to inspect
this documentation at all times consistent with existing document retention
requirements”.)
Required
Changes: none
Impact:
none
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.
Current
Status: Tucows currently does provide the evidence relied
upon for the transfer during and after the applicable Inter-Registrar domain
name transfer transaction(s).
The
3 business day requirement must be related to “a number of requests”. If a registrar receives a request for all
domain transfers for the last year, obviously this request will not be
completed within 3 business days.
Required
Changes: none
Impact:
undefined, the 3 day response time recommendation is dependant on the volume of
requests. The volume of requests cannot
be anticipated at this time.
24. A
Losing Registrar may deny a transfer request only in the following instances;
a. Evidence
of fraud
b. UDRP
action
c.
Court order
d. Reasonable
dispute over the identity of the Registrant or Administrative Contact
e. No
payment for previous registration period (including credit card charge-backs)
if the domain name is past its expiration date or for previous or current
registration periods if the domain name has not yet expired. In all such cases,
however, the domain name must be put into “Registrar Hold” status by the Losing
Registrar prior to the denial of transfer.
f.
Express written objection from the Registrant or
Administrative contact. (e.g. – email, fax, paper document or other processes
by which the Registrant has expressly and voluntarily objected through opt-in
means)
Current Status: Tucows
denies a transfer when there is:
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.
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)
The
Registry will not transfer the domain when it has been placed on registrar
lock. Tucows provides the registrant
with amble opportunity to unlock the domain, and will not placed the domain on
“registrar lock” after a transfer away request has been received (however, the
registrant may do so).
Required
Changes: none
Impact:
none
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.
Current Status: Tucows
does not denies a transfer when there is:
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. (eg – email, fax, paper document or other processes by
which the Registrant has expressly and voluntarily objected through opt-in
means)
c. Domain
name registration period time constraints other than during the first 60 days
of initial registration.
d. General
payment defaults between Registrar and business partners / affiliates in cases
where the Registrant for the domain in question has paid for the registration.
Tucows will not place a domain on registrar hold after a transfer away request has been made. The registrant can however place the domain on registrar hold at any time.
Required
Changes: none
Impact: none
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.
Current Status: Tucows does not have access to such a process, but see great benefits to this process.
Required
Changes: none
Impact:
none
27. That
Registries implement a “Transfer Undo” command that will assist Registrants and
Registrars in resetting a domain name back to its original state in the event
that a transfer has occurred in contravention of the recommendations of this
document.
Current
Status: As a
“transfer undo” command does not currently exist, resetting a domain name back
to its original state is a laborious manual process.
Required
Changes: Tucows would
have to develop an interface to allow Tucows staff to invoke the “transfer
undo” command as required. However, the
cost of this initial development would be offset by the long-term reduction in
manual intervention.
Impact: low
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.
N/A – ICANN directive.
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.
The 3 documents have been reviewed in conjunction
with the preceding recommendations.