Bruce Tonkin in replying to Donna said that changes in software
are likely, and that a reasonable time (e.g 3 months) may be required for full
compliance by registries and registrars (for example note the time taken to
implement the Redemption Grace Period at the Registry level following the approval
by the ICANN Board).
Ross Rader commented about the form of authorization provided
in 3 days ( refer Recommendation 23) response to a losing registrars request.
While it was a reasonable for a limited number of requests for a large number
it became an unwieldy process.
Precise language in the contracts should be added by Louis Touton to allow
some flexibility in time frames depending on the nature of the request.
Elana Broitman commented on copying the registry confirmation e-mail's
so that the registry could have a log.
Bruce Tonkin mentioned that the retrieval process was equally complex
for was the same for Registries as it is for Registrars. Some retrieval may
be automated, but some retrieval would require manual processes.
Bruce Tonkin suggested a standardized header including a time code and
domain name if copying to the registry.
The form of authorization could be in a number of different forms, but the essential
is that the registrar agrees to the transfer.
Tim Ruiz commented on:
Recommendation 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.
Tim Ruiz commented that the last sentence was not clear. Was the intent
that links to the transfer documentation of all registrars would in some way
be available? If so, this would best be done through a central location at the
registries, or perhaps ICANN, since both have contractual relationships and
could enforce compliance.
Bruce Tonkin explained that it was aimed at registrants, who, if they
wanted to change, should be able to get that information. Each registrar is
responsible for providing information about its procedures.
Tim Ruiz commented on: Recommendation 25.
Instances when the Losing Registrar may not deny a transfer include, but are
not limited to;
d. Domain name registration period time constraints other than during the first
60 days of initial registration.
This conflicts with security measures that have been working for us.
For example, we try to offer a simple, yet secure, mechanism for registrants
to transfer ownership of their domain names. As a part of that security, the
new registrant must agree not to transfer the domain away for 60 days. In addition,
registrants transferring domains to us must also agree that they will not transfer
the domain again for 60 days, another security measure.
These are reasonable steps that have little impact on portability, yet add much
security for the registrant, and lessens the likelihood of dispute resolution
procedures. We believe allowing these two "optional" time constraints will improve
security and lessen the likelihood of dispute resolution.
Elana Broitman said that in all the recommendations registrars were
mentioned and asked whether it applied to resellers, and Nikolaj Nyholm
said that in CORE (which operates as an association of resellers) it is left
to each reseller to interpret how they do a transfer or change a DNS. There
may be the same policy, but thereare different implementations. It was noted
that the registrar is the contracting party with the registry and ICANN, and
thus is responsible to ensure it complies with the transfers policy.
Bruce Tonkin said that in Australia resellers are specifically addressed
in contracts and the registrar is responsible to see that the reseller is complying.
Elana Broitman said:
Recommendation #25 may not work with the current deletes task force recommendations.
Right now for purposes of alerting registrants that their name is expiring and
they should renew, the grace period may be used to take the name and place it
on registrar lock. This action would inadvertently trigger a nack under 24 and
25. The registry's rules may need to change to address this discrepancy. . It
was noted that the registry software will deny a transfer is the name is on
HOLD, and that this issue is already covered in recommendation 24(e).
At the same time, if a transfer request comes through too close to the end of
the renewal grace period and the registrant had not paid for the new term, a
losing registrar may not be able to receive reimbursement from the registry
(refer to recommendation 14). Therefore, among the allowable reasons in #24
should be the transfer request coming within 5 days of expiration of a grace
Bruce Tonkin explained that Verisign has an auto-renew process which
charges the current at the beginning of the expiry period. The Registrant is
not renewed with the registrar but the name will show it is renewed in the next
version of the registry WHOIS.
A move to explicit renewal by the registrar would deal with that.
Network Solutions noted a customer service problem here as they use a
3, to 6 days as a grace period after expiration and keep the name. A continuation
of the registration but the autorenewal would not dab at the registrars account,
and there wouldn't be extension for a year unless there was explicit renewal.
Bruce Tonkin suggested an auto-renewal notice could be sent at time of
Elana Broitman continued to comment on:
The Transfers Task Force recommendations 9-10, 12, and 24-25 work together
to create a significant loophole that could leave vulnerable many consumers.
Task Force recommendation 13 does not provide an adequate and timely solution
to protect consumers. Taken together this sub-set of recommendations means that
the losing registrar must trust the gaining registrar to do the authentication
- a) send the approved confirmation message,
b) to the appropriate contact in the losing registrar's Whois,
c) not confuse the registrant with deceptive marketing, and
d) receive a confirming message from the registrant or administrative contact.
Recommendation #12 specifies that this must all be "presumed."
The losing registrar may not deny a transfer even if he/she has reason to know
that the gaining registrar has not followed these steps, has sent an approved
confirmation to the registrant, and has not heard back.
We have seen instances of confusion by registrants, particularly due to misleading
or deceptive marketing practices by large and small registrars and their resellers.
Consumers are transferred against their will, have a hard time returning to
their original registrar and registrars suffer not only from a loss of business,
but customer complaints (at best) for not fulfilling the losing registrar's
A dispute resolution mechanism does not solve this problem - it is lengthy and
expensive. It offers only a post-facto solution even in cases of losing registrars
knowing ahead of time of gaining registrars' malfeasance.
Therefore, we would propose augmenting these recommendations in several ways:
a. In cases where a losing registrar knows or has reason to know that a gaining
registrar has regularly violated authentication requirements or based transfer
requests on deceptive marketing, the losing registrar may deny a transfer request
if he/she does not get a response from the registrant.
I) Such evidence would include:
examples of deceptive marketing messages;
FTC or other similar government body advisory about such registrar's marketing
25% or more of the transfer requests being Nack'ed due to registrants responding
that they do not want to transfer; 25% of such transfers trying to return after
the transfer; or a significant number of complaints lodged with ICANN regarding
the transfer practices of such registrar.
b. The time frame for the transfer process should be increased - to 10-15 days
- to allow the losing registrar to alert the registry of bad practices by the
This could be an out-of-band occurrence (a fairly infrequent one), so that it
would not require a change in protocol.
c. We would propose that the registry could have a list of the registrars that
cannot be responsible for validating registrant requests (losing or gaining)
due to a history of proven bad practices.
This would alleviate the need to make changes in the protocol on a case-by-case
Bruce Tonkin summarized the discussion on the point saying that there
should be a mechanism where fast action can be taken where registrars and resellers
do not conform with the transfer policy. Enforcement should occur after an independent
assessment has been made. The issue is to act quickly when registrars are being
Grant Forsyth stated that the task force conclusions pointed to much
frustration over legitimate transfers and not fraudulent transfers or slamming.Tim
Ruiz noted that this is because over 80% of the transfers are verified by
the losing registrar.
Bruce Tonkin said the general issue was a mechanism to take fast action
when a registrar does not follow the transfer process.
Andrew Sullivan, Affilias registry commented next on recommendation 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;
pointing to the dispute resolution process that would involve registries.
He expressed concern about using the registry WHOIS as there is a problem of
consistency among the various WHOIS and it is difficult for the registrant to
know whether the data is good. It was noted that for EPP based registries such
as .biz and .info the registry WHOIS was the authoritative WHOIS, and this should
be used in dispute resolution.
Bruce Tonkin summarized, saying that it should be stated in the recommendation
what the authoritative information is.
Andrew Sullivan added that in the .org contract, WHOIS will be the official
Andrews Sullivan commented further on:
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 suggests a Transfer Undo function. This is technically feasible, but may
entail further restrictions on the activity permissible on a domain name during
the period when a transfer may be undone. Otherwise, it may be possible to "game"
a system by a series of transfers intended to obscure the "correct" state of
a domain. Without a definition in advance of what these additional restrictions
would be, the Transfer Undo function cannot really be implemented.
His concern was about having to keep huge amounts of back-up data and it was
not obvious which version of the transfer to go back to.
Bruce Tonkin suggested that after a transfer there should be a period
of time so the dispute resolution could be dealt with, without a constantly
Bruce Tonkin commented that Chuck Gomes's report could be used
as a structure for formatting the final implementation report.
Chuck Gomes added that the underlying principle should go forward
for implementation and must have strong registrar support. The registries, were
ready to support dispute resolution, but the criteria should be clearly defined,
and costs should be covered in part by the dispute resolution fees.
Elana Broitman asked if this meant that each registry should have a dispute
There was support for a common policy across all registries.
Bruce Tonkin asked for views on one of the most controversial recommendations,
the losing registrar doing the authentication for the transfer if no response,
it is not an excuse to deny the transfer. He stated that Network Solutions,
Bulk, Godaddy and Register .com had concerns over this recommendation.
In Chuck Gomes's report, there is the option that the loosing registrar
can say they wish to be the party that sends out the authentication message
and if there is no response the gaining registrar takes over authentication.
. If the gaining registrar would get no response he would send the denial to
Bruce Tonkin said that it was not a question of a thick registry but
of the auth-code. The losing registrar does not know if the gaining registrar
has been in contact with the registrant. There is a stronger level of authentication
in the EPP protocol as the authentication is carried out directly with the registrant.
Scott Ableman said that many registrars are uncomfortable with the losing
or gaining registrar being responsible for authenticating the identity of a
person. The person trying to transfer must be verified as the person who set
up the account with the losing registrar (either by email to the user that set
up the account or via the user logging into an account)
Grant Forsyth explained why the process had been set up in the report
and stated that the task force was concerned about the involvement of the losing
registrars for two reasons:
- incentives are wrong for losing registrars to be entrusted with having the
transfer take place
- A registrant may not want to have further dealings with the losing registrar.
Bruce Tonkin summarized the discussion:
A losing registrar has the technical ability to respond quickly to a gaining
registrar that is failing to comply with the transfer policy, by sending a transfer
deny command to the registry.
If there is an official dispute filed the losing registrar could deny the transfer.
What should be brought into recommendation 24 - how does one deny the transfer,
some transfer dispute action.
Jeff Neuman suggested dealing with the converse where the losing registrar
nacks, there should be a dispute resolution for both situations.
In recommendations 24 &25 addressed in Chuck Gomes document, it was
suggested that the list should include other issues which no one has an issue
about, but would complete the list:
- domain lock - registrar should be able to take off domain lock
Next Call assignments:
1. Continue to send comments to the list
2. Draft report for next week for discussion
Next call: Wednesday 22 January 20:00 UTC, EST 15:00/Thursday 23 January,
Bruce Tonkin thanked all the participants and closed the call at 21:40
UTC, EST 16:40, Melbourne, 8:40 Thursday 16, January