Dear TPR WG members, Please find below the brief notes and action items from today’s meeting. The next meeting will be on Tuesday, 06 June at 1600 UTC. Best regards, Emily, Julie, Berry, and Caitlin ACTION ITEMS/HOMEWORK: ACTION ITEMS re: Charter question g3 and additional mechanisms needed to supplement the TDRP: 1. WG members to suggest additional use cases. 2. Staff to suggest in responding to the charter question the WG could a) formulate a question for feedback from the community and b) could recommend that another group could look at a registrant-initiated transfer dispute mechanism. ACTION ITEM: WG members to review the redlined Transfer Dispute Resolution Policy with Rec. 27 updates at: https://docs.google.com/document/d/12ncsCc_sYiBs2cRZVOPCrBes92aV0p-6S-7hNBkm... and note anything that might be missing or require clarification. NOTE: The document is set for editing – please use suggestion mode so that changes are highlighted. Notes: Transfer Policy Review - Meeting #93 Proposed Agenda 30 May 2023 1. Welcome and Chair Updates * Work Plan: Reminder – on meeting #93 and on track to get through the remaining TDRP charter questions – good to get community input during the ICANN77 session. Following that clean up anything on TEAC/TDRP, then go into ICANN-approved transfers. 2. Recap Outcomes - Last Week’s Call 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? Summary: No new recommendations. Respond to charter question by: * Summarizing the limited data reviewed by the WG (published TDRP cases) and note why it is limited (many disputes occur outside of the TDRP) * Summarizing how some limits of TDRP do not necessarily indicate a problem with the dispute mechanism itself, but the limited scope of the policy * Note that the WG believes the TDRP is effective for the limited scope of issues it is designed to address Discussion: * At-Large has indicated support for the registrants to have a way into the TDRP in cases where the process isn’t followed. * The tough part is that with the TDRP there has to be a clear policy violation – although most transfer dispute issues are not policy related. This WG is considering whether to make a recommendation to do something outside of this group. See charter question g3. g2) The ADNDRC reported to the IRTP Part D Working Group that in some of the cases it processed, appellees and appellants failed to provide sufficient information to support arbitration. Is this an issue that needs to be examined further in the context of the policy? 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? Summary: No new recommendations. Respond to charter question by: * Summarizing the data reviewed by the WG ((i) the text of the TDRP relating to the documentary information required to be provided by filing and responding parties, (iii) the specific cases published on the TDRP providers’ websites, (iii) the existing information ICANN org provides on its web pages related to transfer disputes and transfer-related issues.)) * Summarizing how the WG group concluded that the required information to be filed by complainants and respondents is sufficiently clear and no conspicuous gaps exist. It is ultimately on the parties to provide evidence to support their case. The WG did note, however, that future updates to documentary evidence as a result of Rec. 27 must be drafted in a way that is understandable to parties, providers, and panelists. * Note that this may need to be reviewed in the future as more cases are filed to see if any gaps exist. 3. Charter Question g3 (draft scenarios) -- Use Cases from IRTP D Final Report [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/filefi...>, please see pp. 41-42 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? If there is evidence to support that there is a problem, is a new dispute resolution process the best solution? * For example, if the working group believes that domain name hijacking is a significant problem that is not being addressed sufficiently, could the need be met by focusing on protections to prevent improper inter-registrant and inter-registrar transfers from occurring? As a reminder: * The IRTP Part D recommended not to develop dispute options for registrants. * The working group must provide a clear rationale if it believes that further work is needed on this issue. Use Cases * Use Cases from IRTP D Final Report, please see pp. 41-42 * Two registrant claimants dispute to be the Registered Name Holder immediately prior to or directly following an inter-registrar transfer (entirely b/w registrants; no compliance role) * Two registrant claimants dispute who is the Registered Name Holder of a domain name without an inter-registrant transfer having taken place. There are a number of reasons for such a situation to occur, including – but not limited to – a contractor registering a domain for a client, two business partners splitting, admin contact leave a company but remains listed in the Whois database. (entirely b/w registrants; no compliance role) * Any other use cases from the WG that need to be considered? Recommendation #9. The WG recommends that staff, in close cooperation with the IRTP Part C implementation review team, ensures that the IRTP Part C inter-registrant transfer recommendations are implemented and monitor whether dispute resolution mechanisms are necessary to cover the Use Cases in Annex C. Once such a policy is implemented, its functioning should be closely monitored, and if necessary, an Issues Report be called for to assess the need for an inter-registrant transfer dispute policy. Discussion: * Noticed in the two use cases – is that there is no Compliance role. This isn’t going against Policy so there’s no Compliance role. If there’s a gap it’s between identifying an issue, recognizing Policy hasn’t been broken, see what is the next step for registrars – gap between registrars agreeing that they don’t agree, and going to court. Is that the right gap? * It is often the case that registrants unfamiliar with Policy will realize their domain is transferred and do anything they can do to get the name back. From the chat: “additionally, transfer disputes often are raised but the issues are things covered by other policy, such as ERRP or EDDP * ie registrant fails to pay to renew, lazy attention to domain generally and later sees domain at different registrar and claims bad transfer because they do not understand the rules” Want to make sure other policy is followed before we create a new policy. * There’s more than just the transfer policy that affects a name. * Don’t want to encourage overuse on simple transfer issues, such as for non-payment. * Think it would be helpful for staff to understand: One thing to open of transfer policy to former registrants; it’s another thing to have ICANN handle compliance for non-transfer policy issues --- need a panel that had experience with property law, potentially very complicated. Does the WG want to recommend a new dispute mechanism to address a gap – what would it be, what would be the gap/issue to address? * Steinar, ALAC: The gaining registrar says I have captured all the information (followed the transfer policy process) but registrant disagrees – only option is to go to court right now. That is the gap. * Any other use cases – Zak? Is there something lighter weight than going to court? Also the jurisdictional issues are daunting. What wording should we provide in our Report for a recommendation? * Registries don’t have much of an interest, but rather than making a registrant-involved process limited to transfers, but could be broader than that --- where registrants have complaints about registrar practices. * That could be well beyond the scope of this group – not sure what group would drive that. * Staff could 1) send a note to the list re: use cases and 2) suggest in responding to the charter question the WG could formulate a question for feedback from the community and could recommend that another group could look at a registrant-initiated transfer dispute mechanism. ACTION ITEMS re: Charter question g3 and additional mechanisms needed to supplement the TDRP: 1. WG members to suggest additional use cases. 2. Staff to suggest in responding to the charter question the WG could a) formulate a question for feedback from the community and b) could recommend that another group could look at a registrant-initiated transfer dispute mechanism. 4. Charter Question g4 -- Note: Please review Sections 3.1.2 and 3.1.4 of the TDRP<https://www.icann.org/resources/pages/tdrp-2016-06-01-en> in advance of the meeting g4) Are requirements for the processing of registration data, as specified in the TDRP, compliant with data protection law? Discussion: * Think if you start with a TDRP and you use as little personal data as possible, would think a panelist would have a reasonable need for personal data. Put this back to the TDRP provider to make sure the data protection law is being followed. * Address/location may be relevant to determine jurisdiction or physical notice of process (if required). 5. Charter Question g5 -- Note: Please review Sections 3.1.2 and 3.1.4 of the TDRP<https://www.icann.org/resources/pages/tdrp-2016-06-01-en> in advance of the meeting g5) Are requirements for the processing of registration data, as specified in the TDRP, appropriate based on principles of privacy by design and data processing minimization? ACTION ITEM: WG members to review the redlined Transfer Dispute Resolution Policy with Rec. 27 updates at: https://docs.google.com/document/d/12ncsCc_sYiBs2cRZVOPCrBes92aV0p-6S-7hNBkm... and note anything that might be missing or require clarification. NOTE: The document is set for editing – please use suggestion mode so that changes are highlighted. 6. AOB