ALAC Members: Steinar Grøtterød and Daniel Nanghaka
ALAC Alternates: Raymond Mamattah and Lutz Donnerhacke
ALAC Observers: Chokri Ben Romdhane, Hans Bathija, K Mohan Raidu, Sivasubramanian Muthusamy
See: Workspace of the Transfer Policy Review PDP
Transfer Policy seen by Registrants
This chapter is intended to be present as a separate document to the PDP process. It should describe the position of the domain name holder (registrant) in the process of a domain transfer or owner change.
Visible Roles and Communication
The registrant does have a contract with his reseller, which does all the work on the domain name for him. In some case the reseller works also as the DNS-operator, in other cases DNS is self-hosted by the registrant (end customer).
The registrant usually does not know which registrar is handling the domain registration and who is running the registry and/or the RDDS-database. All communication is done via the reseller. Hence any communication bypassing the reseller may cause confusion or is completely lost, unless the reseller is informing the registrant beforehand. That's why any policy should state clearly, which direct communication may occur in which situation, so that the reseller is able to attract the registrants attention to it early and clearly.
The registrant is not allowed to verify it's own RDDS entry by himself. Registrant relies on the reseller on this subject. Maybe there should be a policy to gain access to the full record for the registrant by a standardized method provided directly by the registry.
Inter-Registrar Transfer
The registrant asks the new (gaining) reseller to transfer the domain. He want's to switch the contractor. Often the change results from a bad mood between the old (losing) reseller and the customer (registrant). So the registrant does no want to talk to the old (losing) reseller, if possible.
Authinfo-Code
The gaining reseller tells the registrant to contact the losing reseller, ask for an authinfo-code, switch the domain into an transferable state: ACTIVE instead of LOCKED, and to hand over zone file data. If the losing registrar finds reasons to deny the authinfo code, the regsistrant is in a bad position. How can the registrant enforce an handover of the authinfo code, even if the reseller is unwilling or unable to help? A typical example is a reseller, which was going out of business or try to get some disputed invoices paid.
Gaining FOA
Losing FOA
Risk of lost authinfo-codes
Transfer to wrong registrar (content of losing FOA)
Change of Registrant (aka Owner Change/COR)
Notification about changes
Verify of correct current data
Loss of domain due to fraudulent change of ownership by the reseller
60 day lockdown period
- Survey responses and data provided by ICANN’s Global Support Center indicate that registrants do not understand the 60-day lock and express frustration when it prevents them from completing an inter-registrar transfer. (Information given in the Charter)
COR of Privacy-/proxy registrations
