From: Bruce Tonkin Sent: Monday, 3 March 2003 5:37 PM To: jo.lim@auda.org.au Subject: Response to Draft Transfers Policy dated 24 Feb 2003 Hello Jo, Thank you for the opportunity to comment on the latest draft of the transfers policy dated 24 Feb 2003. (1) Separation of the transfer process from the renew process ============================================================= A major change in the policy is a change from a process where a transfer results in a renewal, to a process where a transfer is completely separated from the renewal process. This is a significant departure from the gtld environment where a transfer results in an additional year of registration up to a maximum of 10 years. I note that Melbourne IT does not charge for a transfer between resellers within its systems. I assume that the registry will not charge the gaining registrar for a transfer under this process. The proposed policy change does make it even more important that a registrant properly authorises a transfer, as there will be a tendency to attempt bulk transfers without the knowledge of the registrant. So I endorse the continuation of the process for registrants to properly authorise a transfer. As others have pointed out, it is possible that registrants may take advantage of some registrars, by: (a) Transfer to a registrar (A) with good customer service at no charge (b) Transfer to a low cost operator (potentially off-shore) at the time of renewal (c) Transfer back to registrar (A) If this activity is significant it will remove the commercial incentives to provide high grades of service, and the overall service quality in the industry will suffer. It remains to be seen whether this behaviour will occur. There is no evidence of it occurring within Melbourne IT's .com.au systems either before or after 1 July 2002, but this is in the absence of low cost and unsustainable resellers within the Melbourne IT systems. Most of the abuse of the Melbourne IT system has occurred via some resellers rather than registrants attempting to game the system. Certainly .org.au and .net.au names have been transferred to registrars at no charge on the assumption that a reasonable proportion of the registrants will renew with that registrar. Effectively the registrant has a chance to assess the quality of the customer service, before committing to renew with that registrar. It is likely that most domain name suppliers will bundle the domain name service with other offerings such as web site hosting, email forwarding, or email service. The cost to the supplier to manage a domain name transfer will thus probably be incorporated into the price of the bundled offering. It will be important for auDA to enforce the code of practice provisions relating to bundling of domain name services, and ensuring that a registrant is adequately informed that there is no technical requirement for a domain name to be managed by the same company as services referenced by the domain name. In the draft policy auDA has specified that a registrar (either gaining or losing) may not charge for a transfer. This is effectively price regulation, but it is at least symmetric. Quite often the amount of work required by the losing registrar (e.g providing the domain name password and assisting with the update of contact details) is similar to the amount of work required of the gaining registrar in the transfer process. While it could be left to market forces to set a transfer fee, it is likely that this would be confused with the renewal process which can only occur within 90 days of the expiry of a domain name. Melbourne IT currently supports the auDA policy to not allow a fee for transfer. If gaining registrars were able to charge for a transfer to recover costs, then it would be equitable for losing registrars to also have that option. It has been suggested by Enetica that transfers be dis-allowed 90 days after a transfer. It should be noted that in the gtld environment transfers are not allowed within 60 days of an initial registration. The intent of that policy was to allow for credit card charge backs, so that a registrar could attempt to obtain payment from the registrant before allowing a transfer away. In the .au environment there is no such ability to deny a transfer. Credit card charge backs however can occur up to 6 months after the initial registration. In a proposed change to the gtld transfers policy, an allowable reason to deny a transfer is if a domain name is within 60 days of being transferred (apart from a transfer back to the original registrar). The reason for this change was to allow time for any dispute resolution to be concluded before the domain name could be transferred again. It is important to note that a transfer back to the original registrar is an exemption - allowing for registrars to resolve a dispute and reverse a transfer. Given that we do not currently in the .au environment have any restrictions on when a transfer can occur (both before and after 1 July 2003), there does not seem to be sufficient evidence to support adding a period, as the inconvenience to the registrant of limited portability probably outweighs any gains. However this will need to be reviewed in 6 months time, because it does assume that auDA will be enforcing the transfers policy and that registrars are complying with the policy. If there is a significant amount of abuse of the policy, and the subsequent need to resolve disputes, then adding a 60 or 90 period of restriction after a transfer could be considered. However this period should not apply to a transfer back to the original registrar. In conclusion the proposed policy to allow no-cost transfers within the current registration licence period can give a benefit for registrants and resellers, but it will require very careful monitoring by auDA to avoid deceptive transfer practices especially associated with bundling. auDA will also need to monitor the behaviour of registrants to see if there is significant evidence of registrants gaming the system by transferring to a registrar for a short period of time to obtain a low cost renewal. (2) Transfer procedure ======================= Melbourne IT supports the improvements to the transfer procedure. Given the comments from Enetica, there is still confusion between the purpose of the domain name password and the need to confirm a transfer using a standard confirmation message. A domain name password merely identifies the holder of that password as an individual with the apparent authority to legal bind the registrant. It operates like an electronic thumbprint, hand written signature or personal seal that is used to uniquely identify an individual. The Standard Transfer confirmation message contains the actual authority for a transfer, which is signed off by the use of the domain name password. It is separated from any terms and conditions that may be buried in a transfer request process used by a gaining registrar (e.g part of a bundled web hosting agreement). A domain name password on its own is like a blank piece of paper with a signature. A transfer confirmation message on its own is like a legal agreement with no signature. The combination of the two elements provides the necessary authority to approve a transfer. The specification of the transfer audit message is a good improvement. The timeframe for sending this message should be specified - ie within 2 days. It is assumed that the contact details may include a hyperlink to a website providing instructions on what to do if a transfer is not authorised. In section 5.3 and section 5.4, there is a mechanism to dispute a transfer. Melbourne IT recommends that the appropriate remedy, should a gaining registrar be found not to have followed the transfer process, would be to allow the original registrar to use the transfer process to transfer the name back. ie the original registrar could get confirmation that the registrant wishes to transfer back. In parallel auDA would need to take appropriate action against the registrar that was not compliant with the transfer policy. (3) Specific wording suggestions to improve clarity ==================================================== Clause 3.2. Suggest change last sentence to: "The combination of these two steps ensures that the "apparent authority", conferred by the domain name password, is supported by "actual authorisation to transfer" using the standard transfer message". Clause 4.4 Suggest change to: "Transfers that have been properly authorised and processed according to the requirements of this policy and any procedural requirements of the registry, will proceed 2 days after initiation by the losing registrar (unless the transfer is accepted earlier by the losing registrar). Note this documents the current procedure as implemented in the registry-registrar protocol. A losing registrar may send an explicit transfer acknowledge command to the registry after receipt of the transfer request message from the registry. If no explicit acknowledge is received, the transfer is automatically completed at the end of the 2 day period. The two days provides time for an audit process to be conducted by the losing registrar. Clause 5.2 Suggest change the first sentence to: "If the losing registrar sends a standard transfer audit message, it must send the message once only, and within 2 days of receiving the transfer request from the registry." This ensures that an audit message is relevant to the transfer transaction underway, and avoids later confusing the registrant. Clause 5.2 Suggest change last sentence to: "If the registrant does not respond to the standard transfer audit message, the losing registrar must not persist in efforts to get the registrant to respond to the audit message." The present wording is too general and would restrict the registrar from contacting the registrant for purposes other than auditing the transfer. Of course the registrar must not attempt to confuse or mislead the registrant, as covered in the registrar agreement and code of conduct. Note the losing registrar cannot delay or prevent a transfer so the second sentence may be redundant. Clause 5.4 Suggest change first sentence to: "If auDA determines that the transfer has not been authorised by the registrant in accordance with this policy, then auDA may allow the original registrar to initiate a transfer back using the transfer policy, or may direct the registry to reverse the transfer." Given that a transfer can be done at no-cost and with no change in licence period, it would be possible for the original registrar to transfer the name back using the registry-registrar protocol commands. In such cases it would be prudent to require the original registrar to obtain explicit consent from the registrant. If the problem was on a large scale, then it would be appropriate for auDA to direct the registry to reverse the transfers as a bulk operation. Domain name transfer - request for confirmation Suggested additional text: "Please note that all registrars must comply with the code of practice (http://www.auda.org.au/docs/auda-2002-26.txt) and the transfers policy (http://www.auda.org.au/docs/auda-2002-08.txt)." As recommended by the ACCC, it is suggested that registrants be reminded of the existence of the code of conduct and transfer policy at the time of the transfer transaction. Transfer audit message Suggested text improvements "We received a notification of a transfer to on . This means that will become the registrar of record for your domain name on . Suggested additional text: "Please note that all registrars must comply with the code of practice (http://www.auda.org.au/docs/auda-2002-26.txt) and the transfers policy (http://www.auda.org.au/docs/auda-2002-08.txt)." Given that some registrants do not read email regularly or open their mail regularly, it would be worth including dates in the audit message to avoid confusion - especially if the registrant subsequently transfers again at a later time. As per the confirmation message, registrants should be reminded of the policy relevant to the transfer transaction. This can be done via a hyperlink, or simply a text Internet address. Regards, Bruce Tonkin