[nc-imp] Transfer Implementation Com. teleconf. minutes January 15, text version

["DNSO SECRETARIAT" <DNSO.SECRETARIAT@dnso.org>]

ICANN/DNSO

     GNSO Council Transfer Implementation Committee Teleconference on 15
January 2003
-----------------------------------------------------------------------

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

Transfer Task Force UserRep - David Safran

The aim of the call:
To discuss the input received on the mailing list from each member of the
committee on implementation issues associated with each recommendation.
Comments to the mailing list archives:
http://www.dnso.org/clubpublic/nc-imp/Arc00
http://www.dnso.org/dnso/notes/20030115/register.com/2003.transfers_task_for
ce_feasibility_impact.htm
http://www.dnso.org/dnso/notes/20030115.NCTransferTF-IA-Afilias.pdf
http://www.dnso.org/dnso/notes/20030115.NCTransferTF-IA-RegisterCom.html
http://www.dnso.org/dnso/notes/20030115.NCTransferTF-IA-Tucows.html
http://www.dnso.org/dnso/notes/20030115.NCTransferTF-IA-Verisign.html

Bruce Tonkin suggested going through the Registries and Registrars
represented on this call to give an open summary of the major issues in
implementing the Transfer task force recommendations.

Nikolaj Nyholm stated that he accepted a general form of transfer by the
gaining registrar with the transfer request. The current issue with EPP
based registries was a suitable way of the registrar providing auth-info
codes.
Different implementation of different registrars in supplying auth-info
codes. Many registrars do not have a system in place where auth-info cades
can be obtained.

Donna asked if software changed would be necessary to implement the
Transfers Task Force recommendations and what the time frames would be to
comply.

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



  ------------------------------------------------------------------------

                 Information from:  © GNSO  Council