The call for the Transfer Policy Review PDP Working Group will take place on Tuesday, 28 March 2023 at 16:00 UTC for 90 minutes.
For other places see: https://tinyurl.com/2p95cn6r
- Roll Call & SOI updates
- Welcome and Chair Updates
- Continuation of Gap Analysis Discussion – Transfer Reversal (working document [docs.google.com])
- Time permitting – Recommendation 27, Wave 1 Items Related to TEAC and TDRP (Transfer Policy Item 4 and TDRP Items 1-5, see pages 53, 55, and 56 of the Final Issue Report [gnso.icann.org])
Apologies: Catherine Merdinger (RrSG), Richard Wilhelm (RySG), Prudence Malinki (RrSG), Crystal Ondo (RrSG)
Alternates: Jothan Frakes (RrSG), Carolyn Mitchell (RySG), Jody Kolker (RrSG), Essie Musailov (RrSG)
GNSO transcripts are located on the GNSO Calendar
Notes/ Action Items
ACTION ITEMS/HOMEWORK: WG members should share any observations/feedback from ICANN76 on the WG email distribution list.
- 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:
- Direct resolution between registrars.
- Notification by Losing to Gaining Rr of problem
- Gaining Rr returns NS to pre-transfer settings (provided by Losing Rr in step 1)
- Interaction to confirm that the transfer was invalid, maybe including evidence
- Requirement for Gaining Registrar to respond within specific time period, like TEAC, with Registry returning domain if no response
- If both Rrs agree, Ry returns domain to Losing (pre-transfer) Registrar and reverses related fees
- Optional escalation to third-party TDRP if not resolved here
- 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?
Potential Limitations Raised by WG Members: Liability concerns for both Registrars (can they be indemnified? I understand this is a significant hurdle for TDRP)
- 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.