[nc-imp] Melbourne IT implementation comments on Transfers Recommendations

["Bruce Tonkin" <Bruce.Tonkin@melbourneit.com.au>]

Hello All,

Melbourne IT supports all the recommendations of the transfers task force, and provides the following implementation input.

Recommendation 5
=================
- requires a registrar to make available information about the transfer process
- this could be included as part of the terms and conditions of registration
- we are concerned that some registrars are using terms and conditions to impose additional constraints on transfers including "All domains that are within 60 days of expiring, 60 days after renewal, or within 60 after being registered are locked and not available for transfer".  The current system allows a registrar to place names in REGISTRAR-LOCK status without any constraints, and this is used to block transfers by competitors.  The registry already incorporates software to block a transfer if the name is within 60 days of initial registration.  Registrars should not be able to provide additional constraints that may limit competition and attempt to lock in the consumer to a particular provider.
- it may be necessary to put constraints on what can be included in terms and conditions in a licence


Recommendation 6
================
- requires a registrar to provide a registrant with the unique "AuthInfo" code within 72 hours
- this is normally easy to implement by providing a web site for the registrant to request the AuthInfo code to be sent to their current email address, or allow the registrant to log-in to the website to retrieve the code directly
- if a registrant does not have the correct log-in details, or their contact email addresses are out of date, there is normally a process required for a registrant to first update their details before they can retrieve this key - a 72 hour period is adequate for processing such a request  (this is also covered in recommendation 7)


Recommendation 8
================
- this is an important improvement
- the standardised form needs to be designed to support the use of multiple languages
- one approach is to include English, and also append some other languages, with a link to a site (which could be maintained by the registry) that contains many translations


Recommendation 9
================
- the losing registrar should also use a standardized for of authorisation
- it would be useful for a losing registrar to establish when it will be doing this second level of authentication so that a gaining registrar may inform the registrant of the losing registrars processes and to request the registrant to respond to the losing registrar


Recommendation 10
=================
- this is the most controversial recommendation amongst registrars, as it stops a losing registrar from denying a transfer when the registrant has not responded to their message
- in the past some gaining registrars have not complied with a rigorous process to obtain authorisation from the registrant
- given that there has been no systematic enforcement or auditing of gaining registrar processes, some losing registrars have decided to take over the role of obtaining authorisation
- the problem is that in many cases the losing registrar sends a marketing communication to try to win the customer back with acceptance of the transfer being a final option, and this is either ignored by the registrant or in some cases blocked by email SPAM filters
- either way the solution is to have a rigorous standardised process for authentication
- ideally the registry or ICANN should do some audited of a gaining registrars process before accrediting the registrar, and also on an ongoing basis to build confidence in this process 


Recommendation 11
==================
- as mentioned in recommendation 9, this message should be standardised and in the same form as the authentication message used by the gaining registrar
- there should be an expected time-frame for when a losing registrar will send out such authentication so that a gaining registrar may instruct the registrant on when to expect the message and how to respond
- ideally the message should be sent within 24 hours of the losing registrar being notified of the transfer
- separate marketing communications are allowed


Recommendation 12
=================
- the process assumes that the gaining registrar complies with the requirement to obtain authentication
- this could be strengthened by requiring the gaining registrar to lodge copies of communications with registrants and in some way lodge the confirmation from the registrant with the registry, so that at least some auditing may be conducted periodically (e.g check authorisations against transfer requests)
- one area that could strengthen the policy and ensure that gaining registrars comply could be to develop a set of graduated sanctions 
- for example a registrar would be unable to request any transfers for a 30 day period following a breach of this requirement


Recommendation 14
=================
- some registrars have issues with payment for the domain name itself that may have resulted from a credit card charge back past the initial 5 day grace period following a new registration
- this should be made consistent with recommendation 24 (e)
- note in the com/net registry a transfer should still be allowed during the 45 day grace period following the auto-renew, provided that the registration period before the auto-renew has been paid for.


Recommendation 15
=================
- provision of the authInfo code should be independent of any other method the losing registrar has to deny the transfer (e.g the registrar can still deny a transfer in the case of a UDRP dispute)
- the authInfo code is purely for providing some authentication for the "identity: of the registrant, it does not confer permission to transfer


Recommendation 20
==================
- it could be useful for at least a period of time, that copies of these communications be lodged with the registry or ICANN to allow an initial audit of processes
- the integrity of the transfer process relies on these copies
- another method of audit could be for ICANN staff to create some random domain names, and use these to check the transfer processes of registrars


Recommendation 21 and 22
========================
- a longer period for a losing registrar to accept or deny a transfer, may allow a losing registrar to carry out some checks before deciding whether to check with the registrant

Recommendation 24
=================
- would prefer to remove the addition of reasonable dispute over the identity of the Registrant or Administrative Contact
- the mechanisms for authentication should cover this (ie using the contacts as identified in WHOIS)

Recommendation 25
==================
- this is an important recommendation for clarity
- there are already registrars inventing their own criteria for when to deny a transfer - including 60 days after a renewal, etc
- there should be one standardised list
- recommendation (d) might be hard to implement - how does a registrar know if the registrant has paid the reseller - generally the reseller is acting as an agent for the registrant.


Recommendation 26 (f)
=====================
- regarding cost of a dispute
- there will be some cases where neither the gaining or losing registrar are at fault.  This typically occurs when a registrant and an admin contact may have a difference of opinion.  The gaining registrar should not be responsible for costs if not "at-fault".  At-fault could be defined as failing to follow the transfer procedures.


Recommendation 27
=================
- this is not directly possible using either the RRP or EPP protocols
- will probably need to be implemented out-of-band (e.g via a registry website)


Recommendation 28
==================
- I recommend that as part of the 3 month review, that there be some systematic auditing of gaining registrar procedures to ensure they comply with the authentication requirements


Regards,
Bruce Tonkin