...

ALAC Observers: Chokri Ben Romdhane, Hans Bathija, K Mohan Raidu, Sivasubramanian Muthusamy

SeeResources: 

• 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

In order to start the transfer, the registrant has to formally start the process (for a paper trail), but reseller does not have access to the RDDS data and therefore can not verify this formal document (called gaining FOA). The only information, the reseller needs to know is the authinfo code, which is sufficient to start the process at the registry by the registrar (commanded by the reseller). So, can the gaining FOA be removed at all? Most registrants are not aware of the gaining FOA either.

Losing FOA

If an transfer process is started by the gaining registrar, the registry sends an losing FOA directly or via the losing registrar to the registrant. This way the registrant could check, that the process is legitimate and started by the correct parties. How can the registrant be empowered to take the unknown, unexpected messaged in a foreign language serious?

Unfortunately the losing FOA does only mention the gaining registrar, which is mostly unknown to the registrant. Can the losing FOA mention the gaining reseller, too?

From the interests of the registrant, can the losing FOA be removed at all, because it's too similar to spam?

Risk of lost authinfo-codes

The authinfo code is usually send via unencrypted email from the losing reseller to the registrant. Even inhouse the authinfo code is mostly handled carelessly by the registrant. There is a good chance to obtain the authinfo code may be leaked to an attacker. The attacker can use the authinfo code to start the transfer earlier, than the registrant itself. How can the registrant notice such an impersonation fraud without a losing FOA? Which data must be included into the losing FOA to prevent this type of attacks?

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)

• ALAC statement of understanding

• Phase 1b - Change of Registrant Discussion (31 August 2022)

  • Presentation
  • Poll Results
• Redline Transfer Policy Review Initial Report (2022-02Feb-15)
• Update from the GNSO-TPR meeting on 8 August 2023 

  • Minutes from the GNSO-TPR meeting on August 8, 2023

    The GNSO-TPR WG discussed the potential expansion of BTAPPA or Transfer Policy around Resellers/Service Providers. BTAPPA is a Registry Service and it is beneficial in situations where one ICANN-accredited registrar purchases (the "Gaining registrar"), by means of a stock or asset purchase, merger or similar transaction, a portion, but not all, of another ICANN accredited registrar's domain name portfolio ( "Losing Registrar") or where a Gaining Registrar receives a request from a registrant to transfer a significant number of its domain names from a Losing Registrar to such Gaining Registrar.

    It is worth mentioned that not all gTLDs have enabled BTAPPA. BTAPPA can be requested by the Registry Operator using RSEP.

    BTAPPA is initiated by the registrar - not by the registrant (as in an ordinary inter-registrar transfer).

    When completed, the status of each domain name is not changed (expiredate, nameservers etc) and there is no fee being passed on to the Registrant due to the BTAPPA.

    From an end-user view, it is of importance that the Registrant has the same rights and obligations when there is a change of sponsorship (change of registrar) for his/her domain name. The WG also discussed if the BTAPPA would include a transfer lock for each domain name when executed.

    At-Large will pay attention and voice if any change in the BTAPPA policy results in changes for the Registrant. SInce the BTAPPA is NOT initiated by the Registrant, no changes (transfer lock etc) should be added.

    There are no statistics of the volume of BTAPPA since this is to be seen as a business agreement between the Registry Operaor and the gaining and losing Registrars.

Statement Workspaces: 

• At-Large Workspace: ALAC Input on Transfer Policy PDP Charter Recommendations Phase 2 G3
• At-Large Workspace: Initial Report on the Transfer Policy Review (Phase1b) - coming soon
• At-Large Workspace: Initial Report on the Transfer Policy Review (Phase1a)  02 Aug 2022 
• At-Large Workspace: Request for Input on Transfer Policy Review PDP Charter04 Aug 2021

...