2023-04-11 Transfer Policy Review PDP WG Call

Notes/ Action Items

 ACTION ITEMS/HOMEWORK:  Staff to initiate a small team to develop a proposal/language to codify the informal transfer resolution process.  Volunteers on the call: Jody Kolker, Rich Brown, Owen Smigelski Juan Manuel Rojas, Zak Muscovitch and Jothan Frakes.

 Notes:

1. Roll Call & SOI updates

2. Welcome and Chair Updates

• Project Workplan: Reminder that early input on Phase 2 topics is due on week from today (18 April).  No open action items.  Hoping to wrap up TEAC/TDRP by ICANN77.

3. Update – Issue Identified at ICANN76 regarding TDRP Section 3.2.4(ii)

• Issue raised by George Kirikos was that if the Gaining Registrar couldn’t provide the Gaining FOA, that could be grounds to reverse the transfer.  Can’t currently provide the FOA due to GDRP.
• Now an explanatory banner noting that not providing the Gaining FOA cannot be grounds for reversal of a transfer.

4. Visual Overview of TEAC, Informal Resolution, and TDRP

• See attached document.

Notes:

• TEAC is just an expedited response to an informal process.
• If registrar don’t agree an option could be to file a TDRP, but this is a lengthy and expensive process, so that may be why it’s rarely used.
• Other options if registrars still disagree are ICANN Compliance and the courts.
• The informal resolution without the TEAC is the focus of our gap analysis.

Discussion:

•  Page 1 – missing is what happens if Gaining Registrar doesn’t make contact within 4 hours per TEAC – ICANN Compliance option.
• Question: Are there policies that the registrar has to respond if the registrant asks to start a TEAC? Courts may not be an easy path.  Answer: The registrar today is the one responsible to initiating the TEAC contact in a transfer dispute.   High 99 percent of the time the registrar is responding to a registrant, but there is no policy obligation to do so.

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

I. Codify Informal Resolution

• Jothan Frakes: Add “Reversion of Name Servers for the domain name in focus” under “Codify Informal Resolution”: We haven't necessarily sounded this out, but in about 50% of the times I have been in the chain or worker on a TEAC-type contact, the DNS reversion sorted out the matter and reversion was not needed.
• Roger: We will cover that next.  Spent two weeks on this section. Make sure the groups come together and are making statements as a group.
• Staff recap of Part 1:  There was some support and some opposition for creating a process around the steps involved in informal resolution, and only where specific actions apply.  Some thought this would create transparency and better metrics, others had concerns about burdens for non-compliance and gaming.  Also seems to be creating a form of TDRP, so duplicative and burdensome.  Invite advocates to volunteer to put pen to paper.

DNS Reversion:

• From Jothan Frakes: Gaining Registrar: Large corporation buys a domain for marketing campaign, staff transfer to a new registrar in the midst of the campaign – resolution was to revert the name servers to the previous domain.  So, wasn’t a transfer dispute but originated there. DNS reversion solved the problem.
• Roger: May have originated in the dispute process, but doesn’t seem to fall in this section, which is focused on whether and how to codify informal resolution.
• Rick Wilhelm: Not really a transfer dispute, more that my domain name is broken. 

Informal Poll: In favor or not to codify the informal process (hands up)

• Note: Registries are not opposed to codifying, unless and until new requirements are placed on Registries.
• To formalize, we may need to form a small group to work on this.
• Codification is a better word here than formalization, as the latter could suggest adding requirements to the current informal process.

In favor: 7

Not in favor: 0

I.A. Additional Element for consideration: DNS Reversal

Discussion:

• Recognition that if we do something it could do impact DNSSEC, but we aren’t here to suggest solutions, but could acknowledge the issue.
• Jim Galvin: Both the NS records themselves and the zone contents that have to be considered and recommendations made regarding the various configurations.
• Didn’t associate Section 1 Codifying to I.A. – these are new issues. 
• Maybe it should be mandatory for the Gaining Rr to revert the NS upon notification of a formal (codified) transfer dispute.  IF that dispute includes the request to revert the NS.
• If there is a trigger to make reversal mandatory/automatic there may not be merit for it.
• If the TEAC is not responsive in 4 hours, everything after that is not automatic.  Someone has to make a decision.
• This reversal shouldn’t be automatic.
• Keep in mind, you can’t just revert the NS.  You have to consider where the zone contents are and make sure those are also “reverted”.
• Think how the reversal would happen should be codified.
• What do you do if there are uncooperative parties? This is very complicated, but if they are cooperative, why bother.  If uncooperative then it would be complicated and a lot of work.
• Codifying would be of the current process to make it more transparent.
• I think even parties who want to cooperate may hesitate if there is not a formal process, as then they may be concerned about liability if it turns out they did the wrong thing? so having a process they can point to as a reason for what they did may help?
• Think there are two issues: 1) codifying for transparency; 2) codifying in more detail in case of disputes.
• My “origin story” for this “codification” mechanism was about helping to ensure that the entire community of Registrars understands the “best practices” of informal resolution that exist between the leading registrars in the industry.  That way, if all the registrars know how to do these informal resolutions, there should be more of them and they should happen quicker and more routinely.
• The most important part of this process is when the registrars don’t agree.
• Three separate things: 1) TEAC for emergency contacts; 2) Codified formerly-informal inter-Rr process for disputes; 3) TDRP for disputes that can't be resolved in 2.
• For the informal process – having a list of steps would be an important checklist and provides consistency.
• May be the next step is to gather a small team to write up the friendly path to be codified, and to help us to see if there is something missing.
• A transfer could still follow the process and still be problematic.
• It’s troubling that the TRP is limited in scope as Sarah points out. I was thinking that maybe a registrant initiated procedure could possibly encompass the other scenarios (in addition to the possibility of revising the current TDRP itself).
• E.g. in TDRP it says "A dispute must be filed no later than twelve (12) months after the alleged violation of the Transfer Policy." - so it requires a violation of the Policy, and describe, in accordance with the Transfer Policy, the grounds on which the Complaint is based…

ACTION ITEM: Staff to initiate a small team to develop a proposal/language to codify the informal transfer resolution process.  Volunteers on the call: Jody Kolker, Rich Brown, Owen Smigelski Juan Manuel Rojas, Zak Muscovitch and Jothan Frakes.

I.B. Additional Element for consideration: Locking

Discussion:

• Should be similar in steps to the DNS reversal among friendly parties.
• Worthwhile also discussing in the small team.
• If there are extended lock periods by mutual agreement, maybe there should be a set of best practices, in particular notifications to the registrant – would those be automatic?

I.D. Additional Element for consideration: “Escalation” to TDRP

Discussion:

• Clarification that everyone is on the same page: TDRP is the next logical step, not automatic.  That is a decision point that has to be made by the parties.

6. AOB