2023-03-28 Transfer Policy Review PDP WG Call

Notes/ Action Items

ACTION ITEMS/HOMEWORK:   WG members should share any observations/feedback from ICANN76 on the WG email distribution list.

Notes:

1. Roll Call & SOI updates

      2. Welcome and Chair Updates

• Reminder -- The deadline for early input from SO/AC/SG/Cs on group 2 topics is Tuesday 4 April.
• Project Plan – No open action items at this time.  Note that we are still anticipating to stick with TEAC/TDRP/transfer reversal for about 2 more months.

      3. Continuation of Gap Analysis Discussion – Transfer Reversal (working document [docs.google.com])

Sarah Wyld: Comments about what an undo process could look like – a lighter weight process that is secure and appropriate:

• Purpose – we need something that could resolve the problem, not just a communication channel (TEAC).
• Need the registrars to work together to resolve the problem:

1. Direct resolution between registrars. 
2. Notification by Losing to Gaining Rr of problem
3. Gaining Rr returns NS to pre-transfer settings (provided by Losing Rr in step 1)
4. Interaction to confirm that the transfer was invalid, maybe including evidence
5. Requirement for Gaining Registrar to respond within specific time period, like TEAC, with Registry returning domain if no response
6. If both Rrs agree, Ry returns domain to Losing (pre-transfer) Registrar and reverses related fees 
7. Optional escalation to third-party TDRP if not resolved here

Discussion:

• Need to suggest time period – what happens if not resolved and by when.
• Suggestion to back up to purpose and use:
• Need something faster and less costly than TDRP.
• Consider timelines.
• Consider how this would specifically be used.
• Is this a formalization of what registrars are already doing?  Could have a process that the domain owner even could invoke, and the point of contact could be the TEAC.
• Concern if this procedure was used for non-emergencies – more than the TEAC is used – what would happen if this was disputed?  How could a new registrant (or losing registrant) participate?
• The registrants (losing and gaining) are both reliant on the registrar.
• Concern that the registrant may not even be informed of the attempt to pull back the transfer.
• How do you get to the point of addressing the participation of gaining or losing registrants? 
• Sounds like we need to keep the concept of the contact for emergencies separate.
• Is it better for the registrant to not have a process?  Can the registrant participate in the TDRP (without the registrar)?  Need a non-emergency resolution process either way.
• There is a big difference between this process and the current procedure – that if the registrar doesn’t respond the registry returns the domain – and the registrant doesn’t have any way of knowing that the transfer has been reversed.  How to address notification?  Does that also include notification to the new registrant?
• Not sure why there is so much concern about returning the domain due to a non-response – doesn’t that already happen?
• Not a concern now since the procedure is seldom used – we assume this new procedure would be used much more frequently.  What happens if a legitimate transfer is reversed?  What is the registrant’s recourse to dispute the transfer reversal?
• The current TEAC system of a response in 4 hours is definitely gamed – need to make sure that any new reversal process can’t be gamed.  Also have to be careful that a RNH couldn’t inappropriately challenge a transfer.
• There are no express obligations for a registrar to advocate for a RNH.  There also are limitations on an RNH’s ability to sue in the case of an illegitimate transfer.
• For a procedures like this to work fairly it would need direct participation by the registrant – could need a registrant initiated transfer dispute mechanism.
• If in step #4, the registrar doesn’t respond does this go instead to a TDRP – would that be better? (Jumps to step #6)?
• If the TDRP is automatically a next step, who would pay for it?
• Courts are where these types of disputes should take place.  Unless there is a clear meeting of the minds, the status quo should prevail.
• As a general principle if we are struggling to say what role the transfer policy is supposed to be then we should take the minimalist approach – just to resolve an egregious and obviously fraudulent transfer.  Leave the status quo as an informal process.
• Should probably err on the side of the losing registrant.
• If the registrars don’t agree then they go to a TDRP.
• There are two equal perspectives – the former owner or the new owner.  This is not a new issue, but we need not resolve it.
• Could we say this process can’t be used if money is changing hands?  If the transfer is due to an illegitimate transfer (a hijack, etc.) it would go through a different process?
• If it is an agreed-upon resolution between registrars there’s no need for a new process – we can stay with the status quo.
• Nice to formalize what is occurring today.

Other comments from Sarah:

Time Period: Maybe only within the 30-day lock period, and if outside that time it must be a TDRP? 

Urgency: Any

Potential Limitations Raised by WG Members: Liability concerns for both Registrars (can they be indemnified? I understand this is a significant hurdle for TDRP)

Discussion:

• 30-day lock would be irrelevant as there is no pull back – if we were to codify the procedure it should be able to invoked at any time (no lock).
• Commencement of the process could occasion a lock.
• The outcome for failure to respond shouldn’t be an automatic transfer – should go to step #6, TDRP.
• Could be a transfer prohibited until the transfer dispute is resolved.
• Is the TDRP the right escalation point?  The policy could be followed exactly but could still be an illegitimate transfer.
• WG could make a recommendation that there could be a registrant-initiated TDRP for fraudulently transferred domains.
• Isn’t returning the domain name to the losing registrar different from ServerTransferProhibited, which is a freeze until the dispute is resolved.

4. AOB