From: Bruce Tonkin 
Sent: Friday, 31 January 2003 7:19 PM
To: Jo Lim
Subject: Submission on auDA transfers policy

Hello Jo,

Thank you for the opportunity to comment on the auDA transfers policy.  I have spent most of January 2003 on 
an implementation report for the ICANN Transfers process.

Melbourne IT is broadly supportive of the present policy as it is close to world's best practice, but there 
are some suggestions for improvement to bring it into line with the international effort in the ICANN forum 
to improve the transfers process.

I have read many of the submissions from resellers and registrars and they are similar to comments in the 
ICANN registrars community over 2 years ago regarding the authorisation process, and the ICANN registrars 
have changed their views.  The auDA transfers policy represents several years of experience already within 
com.au, where problems were arising with deception of registrants causing unauthorised transfers between 
resellers of Melbourne IT.  The combination of the code of conduct and the transfer policy has largely 
stopped this practice.  In the ICANN environment, large numbers of transfers were found to be unauthorised, 
and losing registrars began to exercise their right in the ICANN contracts to deny a transfer if there was a 
dispute over the identity of the registrant (this in itself began to be abused by losing registrars - the auDA 
policy currently prevents this).  The first response to the transfer problem was to develop authorisation 
codes within the registry-registrar protocol (EPP), but these have been found to have addressed only one part 
of the problem (checking the identity of the registrant), but not the authorisation of a transfer.  The ICANN 
Transfers Task Force completed its work last year, and in December 2002 the domain name policy council approved 
its recommendations  (an implementation analysis has just been completed and supports those recommendations).  

A key component of these recommendations is the requirement to in addition to the use of a EPP domain name 
password, that the gaining registrar must also receive confirmation from the registrant using a "standard 
form of authorisation".  It is interesting that the ICANN accredited registrars are requesting this process 
based on several years of operation of transfers.  auDA should not change its policy in this area, given that 
the existing policy is working well and conforms to recently formed international best practice.  The one area 
that the auDA policy does not address is the processes to be used by losing registrars to confirm that 
authorisation has been given, and the processes for dispute resolution where either a gaining registrar has not 
followed policy, or registrants have been misled.

Before making suggestions for improvements, I will first address some of the issues raised by resellers and 
registrars with the current policy.

COMMENTS ON EXISTING POLICY

(1) The claim that the domain name password should be sufficient and that the email address can be easily changed.

- a domain name password only proves that the registrar has been in contact with a person in possession of the 
domain name password - this is a first stage check.  Experience with Melbourne IT registry keys for transfers 
between resellers, showed that many companies were misleading registrants into providing the domain name password.  
For example requesting the password to perform a change in hosting company (via redelegating the domain), without 
informing the registrant that this would involve a transfer of registrar.  An analogy would be giving a person 
my car keys to place or retrieve something in my car, but I do not authorise them to drive my car to another 
location.

- the standardised confirmation email requires a registrant to explicitly agree to a transfer using standard text.  
This is the actual authorisation to transfer.  The domain name password merely shows that the person who gave the 
authorisation has the key.  It is an important safeguard for the consumer, and is consistent with many Internet 
registration systems, where a person that fills in say a website form, is required to respond to an email before 
the action requested on the website is confirmed.  The claim by some industry members that the registrant doesn't 
respond, implies that the registrant may not have been instructed of the process at the time they requested the 
transfer, or it means that the safeguards are currently working.  It is fairly simple to explain that at the time 
a person requests a transfer on a website form, that they will receive a confirmation email which they must 
respond to complete the operation.  This standardised confirmation email is part of the new ICANN Transfers 
process recommended by the Transfers task force that is a result of 2 years of consultation with registrars, 
registries, business users, non-commercial users, intellectual property lawyers, representatives from country 
code operators, and users in general.

- the email address can only be changed via the current registrar.  Many registrars have separate procedures 
(such as user accounts and passwords) for updating the email address that do not involve the domain name password.  
The current registrar can detect fraudulent attempts to change an email address to say the reseller's email address, 
and the policy itself requires that only the registrant can authorise (not the reseller) a transfer.  A registrar 
is required to keep a record of the transfer authorisation acceptance and this can be used in cases of dispute 
resolution if the registrant has not authorised the transfer.

- the present process requires an up-to-date email address.  This is an improvement over past practices where 
the email addresses have become very stale, as they are rarely updated. One of the problems being addressed within 
the ICANN policy environment is WHOIS accuracy, and one of the solutions is to require the WHOIS information to 
be updated at the time of renewal (or at least annually) anyway.  The ICANN Transfer process also requires that 
the registrant correct their contact information before initiating a transfer.

- the confirmation process could be extended to allow a registrar to send and receive a postal response if email 
is not available (or via fax).   This is allowed within the policy proposed by the ICANN Transfers task force.   
However the requirement for a domain name password should also still remain.  The registrar would still need to 
keep copies of these records.


(2) Difficulties in retrieving the domain name password

- the domain name password can be retrieved easily if the email address information is maintained

- whenever Melbourne IT has updated a password it has provided the new password to the registrant via email 
(or postal means if the email address is inaccurate).  auDA now has a new policy in place to address this.

- Melbourne IT also routinely includes the domain name password in written correspondence to   registrants

- the suggestion by Karl Schaffarczyk for alternative methods of retrieving the domain name password (e.g arranging 
for it to be posted to the current postal address) is a good one, and Melbourne IT is very interested in ways to 
lower the quite costly process of manually processing domain name password requests.   Using an automated fax 
system if the fax information in WHOIS is accurate, may be another less costly alternative given the slow and 
expensive process of printing and posting a letter.    Use of email should be encouraged however (it is easily 
automated), and a small processing fee (to be approved by auDA) for a postal approach may provide incentive to 
use email where available, but provide an alternative process where the key may be posted to the current postal 
address.  The free alternative of allowing the registrant to send a request on letterhead and receive the password 
via email would continue to be supported.  Melbourne IT would be happy to work with auDA and the auDA accredited 
registrars to develop improved methods across the industry to retrieve a domain name password when the email 
address details are incorrect.  This is a significant cost burden on Melbourne IT at present, given the failure 
of registrants to keep their details up to date.

- the comment that requests to obtain the key are delayed in any way is not supported by evidence.  A registrar 
is required to respond within a short time (usually less than 2 days) for requests for a new registry key.  If a 
new contact person is involved, then Melbourne IT merely requires a fax of a letter from a company on letterhead 
which is not difficult to provide.  We are looking at further automation in this area, including automatic updating 
of contact details when a registry key is requested.  The updated contact details should be a major benefit in the 
process (although at present Melbourne IT asks the registrant to do this, and we often get repeated requests from 
the same registrant in the space of days for the password again as they have misplaced it, and not updated their 
contact details!).


(3) Lack of choice in hosting

- there is no need to change registrar when changing a hosting provider.  A domain name is like a car licence; you 
can drive any car with it.  There are cases of misleading marketing whereby registrants are told that they must 
change registrar to change hosting provider.  A domain name record contains a pointer for any website location or 
email address provider. The pointer can be changed at any time during the lifetime of the domain name.  Given that 
a registrant has an existing licence that allows unlimited changes of website or hosting providers, it is difficult 
to see why they would change registrars apart from at renewal time.


(4) Need to change registrar to provide a consistent management interface

- A domain name management interface provided by a registrar or reseller is independent of the interface a reseller 
or registrar uses to communicate to their upstream provider (whether registry or registrar).  For example Melbourne 
IT provides a consistent management interface to its registrants, but the back end communicates to many different 
registries, registrars and resellers around the world.  Many of Melbourne IT's reseller customers also act as 
resellers for other registrars, and manage to provide a consistent management interface to their customers.  This 
is part of competitive differentiation amongst domain name providers.

- A domain name reseller can easily suggest that at the time of domain name renewal that the registrant change 
registrars - this could be done via price incentive (e.g with registrar A it costs $x or with registrar B it 
costs $y).  Just as a mobile phone retailer may have agreements with various providers (e.g Telstra, Optus, and 
Vodaphone), and will advise customers on the best price/service offering to meet the customer requirements.  For 
example one operator may have better coverage or be more reliable at a higher cost.  A domain name reseller can 
distinguish itself in the market by providing choice of registrars for its clients, and it actually increases their 
independence and reliability to not be constrained to a single upstream provider.  Certainly Melbourne IT uses 
multiple independent telecommunications carriers to ensure choice and reliability for voice and data services, 
with intelligent routing.


(5) Loss of existing registration period at the time of registration

- International best practice in this area involves adding to the existing registration period up to some limit 
(e.g 10 years)

- The present policy allows for a 2 year registration period to be added if the transfer occurs within 90 days of 
renewal

- Melbourne IT supports the proposal by Enetica to allow 2 years to be added to a registration that is within 18 
months of the expiry date.  This would effectively put a limit of 3.5 years on a registration.  We understand that 
the concern from auDA is that the reasons for eligibility or the contact information will get out of date if no 
contact with the registrant occurs for up to 3 and half years.  Melbourne IT suggests that auDA follow one of the 
recommendations from the ICANN WHOIS Implementation committee for registrars to be required to annually remind 
registrants to check their contact data and update it (there is no requirement for registrars to manually vet this 
data, just a requirement to present the current data to the registrant and ask them to check and update if necessary).  
The lack of accurate contact data has been identified in several submissions as causing problems in the domain name 
processes.  A 3.5 year maximum period balanced by a need to remind registrants to update their contact data is a 
reasonable compromise.

- another alternative would be for the registry to offer differentiated pricing.  e.g different prices for 
transfers within 90 days, 6 months, 12 months or 18 months of expiry date.

- overall however apart from resellers or registrars, Melbourne IT has seen little demand from registrants for this 
change, as for most there is no need to change registrar within their current registration period given that they 
can use their domain name with any website or email provider.  For example a car licence allows you to drive any 
car, and if a person moves to another state or country they rarely obtain a new licence until their old licence 
expires.  The ICANN experience (and also the experience with Melbourne IT resellers within com.au) is that most 
changes between registrars still occur at the time of renewal of the licence, where a better price bundle is offered.  
A domain name supplier that offers bundled services can still offer web hosting or email forwarding on a current 
domain name licence, and then transfer the licence when the current licence expires.


PROPOSED ADDITIONAL POLICY AREAS

(a) Standardise the process for a losing registrar to confirm a transfer

- the auDA environment and the ICANN environment allows for a losing registrar to confirm with a registrant if 
a transfer has been authorised.  This process has been abused within the ICANN environment.  Note the auDA 
implementation does not allow a losing registrar a mechanism to deny a transfer.  This has minimized many of 
the disputes that occur in the ICANN environment, but also created an open loop system where little auditing of 
a gaining registrar's processes occur, and there are no formalized mechanisms of re-dress for the affected losing 
registrar.

- auDA should take a proactive response and use the ICANN approach of requiring a standardised message from the 
losing registrar in the same form as the original confirmation email.  This standardised message should be sent 
within a timelimit from the original transfer request (e.g 24 hours).   Melbourne IT will be following the ICANN 
approach.

- for a losing registrar this provides an audit process to ensure that the gaining registrars are following policy.  
Melbourne IT did a small audit in mid 2002 and found at least one registrar that was not complying with the 
transfer policy, and found that registrants wanted their names returned to Melbourne IT.  In these cases it seems 
a registrant was mislead to transfer between registrars when they were merely selecting a different website 
hosting provider.  This also seemed in contravention of 3rd line forcing requirements in the Trade Practices Act.

- in compliance with the new transfer policy recommend by the ICANN Transfers taskforce, Melbourne IT will be 
initiating an automated audit process


(b) Provide a Transfer Undo mechanism

- the ICANN Transfers task force has recommended that registry operators implement a transfer undo mechanism 
(or process), where a registrant wishes to return to their original provider - possibly out of confusion or 
misleading practices by a registrar.

- auDA should consider requesting that AusRegistry provide a streamlined method of performing a transfer undo command.  
A process may require auDA approval for each such change to ensure that the transfers policy is being applied 
correctly, or AusRegistry may accept approval from both the gaining and losing registrar for an undo operation.


(c) Provide a dispute resolution mechanism

- the ICANN Transfers Task Force has recommended that a dispute resolution mechanism be set up to resolve disputes 
between gaining and losing registrars

- the simplest mechanism would be to ask auDA to do this at least at the first level. auDA's role would be to 
confirm that the relevant registrar has complied with the transfer policy.  It would not be to resolve disputes 
between individuals that each claim to be the registrant.  auDA could provide a cost recovery charge for this 
service (the complaining registrar could pay, but if the other registrar was found to violate the policy than they 
would be required to pay the fee).  If necessary a second level dispute process via an independent arbitrator 
could be used.

- if a gaining registrar is found by auDA to have violated the policy, then auDA could direct AusRegistry to 
reverse the transfer via an undo mechanism

- Melbourne IT did obtain evidence of unauthorised transfers as a result of its audit process in 2002, but found 
that there was no clear process to use to resolve the transfers, and in some cases Melbourne IT paid on the 
registrant's behalf to reverse the transfer.  Resource limitations reduced further follow up as the procedures were 
adhoc with no automation.  Given that Melbourne IT will be automating audit checks in 2003, we expect to more 
routinely identify instances where a transfer has not been authorised.  

- Melbourne IT would like auDA to establish a clear process for a registrar to raise a complaint that includes what 
evidence needs to be supplied.

- a registrant will need to raise a complaint via a registrar so that auDA will only receive complaints after the 
registrar has first conducted due diligence (e.g tried to resolve the issue with the other registrar directly).

- ICANN will be working on the details of the dispute resolution process shortly and this could be helpful for 
developing a local version (much as the auDRP process was modeled on the UDRP process)

Please feel free to contact me if you require clarification on any of the points above - particularly in the 
areas of new policy suggestions.  auDA has tended to lead the way internationally in the transfers area and the 
international environment has been catching up.  We have the opportunity to pro-actively pick up on some of the new 
recommendations coming from ICANN that will further strengthen the auDA process.

Regards,
Bruce Tonkin
Melbourne IT