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

Resources: 

  • Workspace of the Transfer Policy Review PDP
  • ALAC statement of understanding
  • Phase 1b - Change of Registrant Discussion (31 August 2022)

  • 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: 

  • No labels

6 Comments

  1. Please fill in use cases and interesting corner cases. Use italics to refer to standardized objects in the process.

  2. Replaced WHOIS with RDDS (Registration Data Directory Service)

  3. Poll held at the CPWG regarding the 60-days transfer lock questions.

    Email sent on Nov 23, 2021 to the TPR Work group members.

    Dear TPR Work Group members,

    The Consolidated Policy Working Group (CPWG) is the At-Large forum for discussing policy related issues and giving advice to the ICANN community.

    At-Large is represented in the GNSO transfer Policy Review Policy Development Process (TPR-PDP) with 2 members, 2 alternates and 4 observers.

    The At-Large TPR-PDP members continuously inform the CPWG members about the progress in the TPR-PDP working group and seek feedback and advice in essential questions given by the work in the TPR-PDP.

    In order to get the CPWG input to questions connected to preventing transfers to be initiated and executed after an initial registration of a generic domain name, and after a successful transfer between accredited registrar of a generic domain name, a “poll” was held during the CPWG meeting on November 17 2021.

    The “poll” was conducted based on the discussion held at the CPWG meeting on November 10 2021 and the email communication on the CPWG mailing list.

    While not mandated in ICANN policy, some Registry Operators have provisions in their Registry Agreement that require a 60-day inter-registrar transfer lock after the initial registration of a domain name AND/OR after a successful inter-registrar transfer. Note: This should not be confused with Change of Registrant requirements where a “material change” of name or email address will also lock the domain against inter-registrar transfers for 60 days following the Change of Registrant, if the registrant does not opt-out of this lock. Some TPR-PDP working group members have noted that this practice of post-domain creation locks or post inter-registrar transfer locks are not consistent across the industry, which may be confusing for registrants. Some TPR working group members believe that the working group should recommend that the Transfer Policy include requirements for the 60-day lock after initial registration, although the working group is still discussing the rationale for doing so.

    During the CPWG meeting that was held, it was a privilege to have some members who were historically available during the creation of the 60-days lock. This gave the members a real understanding of the lock. The 60-days lock was introduced in 1998/1999 to reduce credit card fraud and chargeback. The majority of the CPWG members argued that credit card checks and chargeback is no longer a problem.

    When questioned, a significant number of the CPWG members were in favour of not defining an ICANN policy requiring a 60-days lock after an initial registration of a domain name. 

    The result of the poll questioning whether an ICANN required policy for a 60-days lock after a successful inter-registrar transfer, indicated a majority was in favour of not defining an ICANN policy of a 60-days lock after a successful transfer. However, the number for keeping a lock after a successful transfer was higher than for having a lock after an initial registration of a domain name. CPWG members signaled that locking a domain name after a successful transfer reduces the possibility for “registrar hopping ‘’ i.e. changing registrars to prevent paying and (often) continuing with suspicious activity as security threats.

    An issue of Domain Hijacking was sighted as a pro when the domain lock is disabled. Hence the need for poll questions connecting to whether there should be an option for registrars and registrants to “opt-out” of locking a domain name for transfer either after the initial registration or a successful inter-registrar transfer, indicated that this should NOT be an option.

    Finally, the CPWG members were asked to get their view on whether the “60-days” was the preferred number for a transfer lock after a successful inter-registrar transfer. The poll’s alternatives were “yes” (keep the 60-days), “lower than 60 days”, “higher than 60-days” and “Abstain/not sure”. A majority of the CPWG members were in favor of a lower number of days locking a transfer after a successful inter-registrar transfer.

    It must be emphasized that the outcome of the “poll” is NOT the final input to these questions. The poll result MUST be seen as a guidance to At-Large TPR-PDP members.

    Regards,

    Steinar Grøtterød

  4. Mar 22, 2022: Email to GNSO TPR WG members re the transfer locks:

    AT-LARGE INPUT TO THE DISCUSSION OF POST-CREATION AND POST-TRANSFER LOCKS

    The Consolidated Policy Working Group (CPWG) is the At-Large forum for discussing policy related issues and giving advice to the ICANN community.

    At-Large is represented in the GNSO transfer Policy Review Policy Development Process (TPR-PDP) with 2 members, 2 alternates and 4 observers.

    The At-Large TPR-PDP members continuously inform the CPWG members about the progress in the TPR-PDP working group and seek feedback and advice in essential questions given by the work in the TPR-PDP.

    In order to get the CPWG input to questions connected to post-creation and post-transfer locks, an informal “poll” was held at the CPWG meeting on March 16, 2022.

    In front of the meeting, information about the discussion and work done by the GNSO TPR-PDP were distributed to the CPWG members. The information also included the “poll questions”.

    The “poll questions” were conducted based on the work done in the TRP-PDP. In addition, the “poll” included a question reflecting CPWG input to a mandatory policy for all Registry Operators.

    The poll questions and the results

    For the post-creation lock question

    What lock period will be of preference:

    • 10 days post-creation lock: 31%
    • 30 days post-creation lock: 59%
    • 60 days post-creation lock: 7%
    • Not sure: 0%
    • Abstain: 3%

    For the post-transfer lock question

    What lock period will be of preference:

    • 10 days post-transfer lock: 41%
    • 30 days post-transfer lock: 45%
    • 60 days post-transfer lock: 7%
    • Not sure: 3%
    • Abstain: 3%

    For the question regarding Registry Operator 

    • Same policy for all Registry Operator: 76%
    • A Registry Operator MAY define a different transfer lock policy: 14%
    • Not sure: 7%
    • Abstain: 3%


    Please note that the 30 days alternative is added to the poll to get more alternatives. The 30 days locks are not discussed as an alternative in the TRP-PDP WG.


    The result may be seen as:

    • CPWG is in the opinion that the present practice with a 60 day post-creation and post-transfer lock is too long.
    • The poll may signal that there could be a different lock periode between the post-creations and the post-transfers.
    • A significant number of CPWG members favors that the updated Inter-Registrar Transfer Policy should be the same for all Registry Operators. In our opinion, this makes it more user friendly by having a level playing field across all operators.


    We emphasize the fact that the results of the poll and this feedback to the TRP-PDP is informal and may not reflect At-Large view when the PDP is up for vote to be finalized.


  5. Summary of BC Transfer Policy Working Group Call

    (Submitted to the GNSO TPR PDP on Apr. 5, 2022)

    Post-Creation Lock

    Ten days is too short. Leave it at 60 days if possible. Maybe 30 days is a happy medium, but 60 days is still preferable. The longer the better from a trademark enforcement perspective as it prevents having to redo a UDRP or demand letter, and also assists with preventing registrar hopping when a registrar is asked to take enforcement proceedings against an infringing or unlawfully used domain name.

    There may be an issue in shortening the period from a registrar’s perspective, in that a registrar customer may take advantage of promotional / loss-leader type pricing for the initial year and then the customer moves away to another registrar.

    Change of Registrant Lock

    The default rule should be a transfer lock following a change of registrant. However, a registrar should be required in a transparent manner, to enable a registrant, upon request to opt-out of the transfer lock or to reduce the transfer lock, rather then leave it to each registrar to decide whether they will generally permit opt-outs. Nevertheless, each registrar should retain discretion as to whether to permit a transfer even if the registrant has ostensibly opted out, for security reasons. A transfer lock should not prevent registrants and businesses from effecting bona fide transfers when necessary or desirable. There should be a fact-based rationale for the determination of the length of the default transfer lock, whether it is 60 or 30 days, for example. A BC member is looking to see whether Domain Abuse Activity Reporting data can provide any insight into the appropriate length for transfer locks.

    Change of Registrar Lock

    This lock does not appear to be of significant concern as it would usually coincide with a change of registrant lock. However, a registrant should not be prevented from transferring a domain name from one registrar to another, even after a recent registrar change, unless there is another type of lock at play.

  6. Steinar Grøtterød

    In support of 60 days Lock-in

    Threat actors register thousands of new domains daily, preparing for future malicious activities such as serving command and controls (C2), hosting malware and delivering deceptive content.  

    The majority of existing domain abuse detectors are based on DNS lookup patterns of ongoing attacks and active crawling on the web content for malicious indicators. For many reasons the discovery has inherent delays. 

    Palo Alto Networks has a proactive tool to detect potentially abused domains as quickly as possible. Malicious domains are detected at the time of registration based on their registration records leverages predictive indicators from WHOIS records. The predictive indicators include abused network hotspots, bulk domain registrations and abnormal registration behaviours.  FINDING: Around 1% of active attacks happen even after 30 days of registration. Typical tools DO NOT  block 60% of the malicious DNS traffic until roughly 30 days after domain registration. 

    SAFETY: 60 days Lock-in on Transfers

    Alan Greenberg This also relates to your presentation on DNS Abuse during the CPWG Meeting on 14 April 2022 IST. As you rightly observe regulation of contracted parties is feasible in ICANN. I know that Censorship is not the way ICANN functions.

    • Dr. T V Gopal