Dear TPR WG members,

Please find below the brief notes and action items from today’s meeting. 

The next meeting will be in two weeks on Tuesday, 27 June at 1600 UTC.

Best regards,

Emily, Julie, Berry, and Caitlin

ACTION ITEMS/HOMEWORK:

1. Re: Charter question f5: WG to consider the feasibility of the recommendation of email to “start the clock” for the 24-hour response timeframe.
2. Re: Charter question g3: WG should consider the two types of disputes – inside and outside the policy – and provide additional rationale/comments.

Notes:

Transfer Policy Review - Meeting at ICANN77

Proposed Agenda

15 June 2023

1. Chair Welcome

• In this meeting we’ll summarize the WG’s accomplishments since ICANN76 on the TEAC and TDRP charter questions.
• We won’t meet next week – next meeting is in two weeks on Tuesday, 27 June.

2. Overview of Working Group's preliminary agreements related to Transfer Emergency Action Contact (TEAC) – see attached slides

f2/f3) The time frame (4 hours) for registrars to respond to communications via the TEAC channel has been raised as a concern by the Transfer Policy Review Scoping Team and in survey responses. Does this timeframe need to be adjusted?

DRAFT REC: The working group is recommending that the policy must be revised to update the required timeframe for initial response from 4 hours to 24 hours / 1 calendar day.

f4) Is additional guidance needed to define a “reasonable period of time” after which registrars should be expected to use a standard dispute resolution process?

DRAFT REC: The working group recommends that the Transfer Policy must be updated to state that the initial communication to a TEAC is expected to occur no more than [30 days] following the alleged unauthorized loss of a domain.

DRAFT REC: Once a Gaining Registrar has provided an initial non-automated response to a TEAC communication as described in Section I.A.4.6.3 of the Transfer Policy, the Gaining Registrar must provide additional, substantive updates by email to the Losing Registrar every 72 hours / 3 calendar days until work to resolve the issue is complete. These updates must include specific actions taken by the Gaining Registrar to work towards resolution.

f5) Do telephone communications provide a sufficient “paper trail” for registrars who may later wish to request a transfer “undo” based on failure by a TEAC to respond? Should the option to communicate by phone be eliminated? Is an authoritative “system of record” for TEAC communications warranted? If so, what are the requirements for such a system?

DRAFT REC: The working group recommends that initial communication to the TEAC described in Section I.A.4.6.2 of the Transfer Policy must either be in the form of email or be accompanied by an email communication to the TEAC. This email “starts the clock” for the 24-hours response timeframe specified in Preliminary Recommendation #G2-1. The Gaining Registrar receiving the TEAC communication must respond by email within 24 hours.

Discussion:

• Luc: Concerned about recommendation for email contact for TEAC.  Don’t have the capacity – could miss an email.  WG can look at that.
• Sarah: Thanks for raising that very good point. Luc raises a good point - I was thinking from the opposite perspective, a phone call doesn't create paper trail and that makes me nervous, but email is hard to stay on top of in a different way than phone.

ACTION ITEM: WG to consider the feasibility of the recommendation of email to “start the clock” for the 24-hour response timeframe.

3. Overview of Working Group's preliminary agreements related to Transfer Dispute Resolution Policy (TDRP) -- see attached slides

g1) Is there enough information available to determine if the TDRP is an effective mechanism for resolving disputes between registrars in cases of alleged violations of the IRTP? If not, what additional information is needed to make this determination?

WG noted that small number of filings does not, alone, indicate an issue with the TDRP - the scope of the TDRP is very limited, and the WG believes it is an effective mechanism to address the types of disputes it was designed to address: alleged violations of the Transfer Policy

g2) Are the existing informational materials about the TDRP sufficient to ensure that registrars understand the process and the requirements for filing a dispute, including the information they need to give to the dispute resolution provider?

• WG noted the TDRP requirements are sufficiently clear and do not need adjustments at this time
• WG noted that for requirements that change as a result of new policy recommendations need to be drafted in a clear and user-friendly way to assist parties, providers, and panelists

g4/g5) Are requirements for the processing of registration data, as specified in the TDRP, compliant with data protection law? Are the requirements appropriate based on principles of privacy by design and data processing minimization?

WG noted some TDRP evidentiary requirements need to be updated based on EPDP - Temp Spec - Phase 1, Rec. 27, including outdated terminology, as well as Transfer Policy Review WG Phase 1(a) - removal of Gaining FOA

4. Open discussion with Community Participants: what are the pros and cons of recommending a transfer dispute resolution for registrants? -- see attached slides

g3) If the TDRP is considered to be insufficient:

i. Are additional mechanisms needed to supplement the TDRP?

ii. Should the approach to the TDRP itself be reconsidered?

• Registrants who believe a violation of the transfer policy has occurred currently have 3 options:

• Request registrar to resolve the issue informally with other registrar
• If informal resolution is unsuccessful, convince registrar to file TDRP
• Go to court

• Some WG members have noted this is not ideal for registrants and believe a new mechanism may be needed

Is there support or not for a recommendation for the GNSO Council to request an Issue Report?

Pros:

• Provides an additional option for registrants who believe a transfer policy violation has occurred and:
• Registrar does not wish to file a TDRP
• Registrar is unresponsive
• Potential time + cost savings

Cons:

• New mechanism could result in increased abuse and gaming
• TDRP requires a lot of documentary evidence that the registrant likely does not have
• Some have proposed new mechanism to address more than transfer policy violations (such as domain theft), which would introduce a lot of complexity (property laws across jurisdictions, such as bona fide purchaser laws)

Discussion:

• Theo: If a registrar doesn’t wish to open TDRP there’s nothing a registrant can do.  It shouldn’t only be up to the registrar.  Makes sense to widen the scope of the TDRP to include a filing from a registrant.
• Steinar, At-Large: Expect that there will be some tuning between registrars when implementing the new policy.  During this time there might be glitches and the registrant may not have support from the registrar.  Don’t like that the only option is to go to court.  It is not an easy process.  Suggest there should be a way for the registrant to initiate a transfer dispute within the TDRP.
• Roger: We made quite a few changes to security measures in Phase 1a, which should reduce disputes.
• Owen (not a Registrar position): Violations of policy are already addressed.  Don’t think registrants should have access since they are likely to bring in disputes that are outside the transfer policy; also courts may be expensive but the TDRP is not free --- it can be expensive too.  Registrant can also bring a complaint to ICANN Compliance.
• Zak: Transfer Dispute Policy: Limited scope has allowed a more successful mechanism – the informal dispute process. BC’s interest in the Transfer Policy is from a registrant’s perspective and from that perspective it’s a flaw that the Transfer Policy doesn’t have a registrant option.  Simply: the registrant would like to be able to initiate a dispute.  As to the registrant not having the evidence, but it could request that from the registrar.  Two possible disputes: 1) violation of the policy; 2) domain name theft/hi-jacking. In the second type it may not be useful or feasible to sue the registrar, and it would be very expensive.  There should be an alternative option.  It might be complicated but still possible nonetheless.  This is a WG so this is not in scope, but it could recommend an Issue Report could consider a new dispute mechanism for registrants.
• Theo: Good discussion around support for a registrant initiated dispute.  Even with this the issues of expense will still exist.
• Holida, ICANN Compliance: ICANN’s authority extends to the enforcement of the requirements outlined in the agreements it has with contracted parties and ICANN consensus policies. If a failure to comply with the agreement or policy is found, Compliance addresses the identified noncompliance with the registrar, but will have no contractual authority to return the domain name or instruct the registrar to return the domain name to previous registrant.  Compliance still encourages registrants to file complaint with us, so we investigate and require registrars to take corrective action in case of noncompliance so instance of noncompliance does not continue/repeat. In some instances, registrar may take its own initiative and assist registrant in getting the domain back, but it’s not obligated by the current policy/RAA.
• Roger: Sounds like there is agreement to provide a recommendation to request an Issue Report on a registrant-initiated transfer dispute policy.

ACTION ITEM: WG should consider the two types of disputes – inside and outside the policy – and provide additional rationale/comments.

5. Closing