http://www.dnso.org/dnso/mp3/20030109.GNSOTF-transfer.mp3
http://www.dnso.org/dnso/notes/20030108.Transfer-Imp.teleconf.html

ATTENDEES:

Registrar - Bruce Tonkin
Registrar - Nikolaj Nyholm
Registrar - Tim Ruiz
Registrar - Ross Rader (with Alain Hutchison)
Registrar - Donna McGehee
Registrar - Elana Broitman
Registrar - Steve Miholovich (with Scott Ableman )
Registry - Jeff Neuman
Registry - Chuck Gomes
Registry - Andrew Sullivan
Transfer Task Force User Rep - Grant Forsyth

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.
Comment:
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 period.

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 expiry.
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 fiduciary role.
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 practices;
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 gaining registrar.
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 basis.

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 misled.
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
http://www.dnso.org/dnso/notes/20030115.NCTransferTF-IA-Afilias.pdf

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 authoritative source.
Andrews Sullivan commented further on:
Recommendation 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.
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 changing environment.

Bruce Tonkin commented that Chuck Gomes's report could be used as a structure for formatting the final implementation report.
. http://www.dnso.org/dnso/notes/20030115.NCTransferTF-IA-Verisign.html
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 resolution policy.
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 the registry.
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, Melbourne 07:00

Bruce Tonkin thanked all the participants and closed the call at 21:40 UTC, EST 16:40, Melbourne, 8:40 Thursday 16, January