Hello TPR WG members, The TPR Working Group will be meeting this Saturday, 21 October, at 08:30 UTC (10:30 Hamburg time) for ICANN78. Please find the proposed meeting agenda below. As a reminder, today is the deadline to submit comments on the Changes to Bulk Transfer Recommendations Google Doc<https://docs.google.com/document/d/1_T41SQAH3duIPS9qhYE71iM5CAxpA3KUpgy55DK3...>. If you have any substantive concerns regarding these preliminary recommendations, please submit them by end of day. Thank you, and we look forward to seeing you in Hamburg/virtually! Kind regards, Christian, Caitlin, Berry and Julie Transfer Policy Review - Meeting #108 Proposed Agenda 21 October 2023 1. Welcome and Chair updates 1. Recommendations from ICANN-approved transfer (bulk transfers) are now in a stable condition 2. We will be briefly revisiting some open questions from other Group 2 topics before transitioning back to a recap of what the WG has agreed to date, and then moving to Group 1(b), which is Change of Registrant (Part II of the Transfer Policy). 3. Working Group Member updates or Stakeholder updates 2. Transfer Dispute Resolution Policy (“TDRP”) – Registrant Access 1. Reminder of current draft recommendation * Relevant charter question: 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? * Current Draft Preliminary Recommendation: The Working Group recommends the GNSO request an Issues Report or other suitable mechanism to further research and explore the pros and cons of (i) expanding the TDRP to registrant filers and (ii) creating a new standalone dispute resolution mechanism for registrants who wish to challenge improper transfers, including compromised and stolen domain names. In making this recommendation, the Working Group recognizes that if such an effort were ultimately adopted by the GNSO Council, this request could be resource-intensive and will require the Council to consider the appropriate timing and priority against other policy efforts. * ALAC message re: registrant access to TDRP<https://mm.icann.org/pipermail/gnso-tpr/2023-July/000945.html> 1. Options in light of ALAC feedback and previous discussion · Require registrar-provided rationale in the event registrar refuses to file TDRP · Registrant responsibility for TDRP fee · Open TDRP to registrant filers (where registrant is responsible for payment of fee, irrespective of outcome – similar to UDRP). In this case, also similar to UDRP, the registrars would be responsible for registrar verification of data. · Leave recommendation as is · Other Options? 3. TDRP updates in light of EPDP – Temp Spec – Phases 1, Recommendation 27 1. Refresher of EPDP Team Recommendation #27. “The EPDP Team recommends that as part of the implementation of these policy recommendations, updates are made to the following existing policies / procedures, and any others that may have been omitted, to ensure consistency with these policy recommendations as, for example, a number of these refer to administrative and/or technical contact which will no longer be required data elements: · Registry Registration Data Directory Services Consistent Labeling and Display Policy · Thick WHOIS Transition Policy for .COM, .NET, .JOBS · Rules for Uniform Domain Name Dispute Resolution Policy · WHOIS Data Reminder Policy · Transfer Policy · Uniform Rapid Suspension System (URS) Rules · Transfer Dispute Resolution Policy 1. Proposed updates to TDRP in light of Rec. 27 · Relevant Excerpt from ICANN Impact Paper: “TDRP section 3.2.4 provides that a panel appointed by a TDRP provider will “review all applicable documentation and compare registrant/contact data with that contained within the authoritative Whois database and reach a conclusion not later than thirty (30) days after receipt of Response.” This provision relies on comparison with the "authoritative Whois database," which does not have a clear analogue in the new Registration Data Policy.” · ICANN Impact Paper notes: o Data could be requested by the panel (similar to UDRP), though that may result in duplicative data; OR o Requirements could be written at a higher level o In the current draft<https://docs.google.com/document/d/12ncsCc_sYiBs2cRZVOPCrBes92aV0p-6S-7hNBkm...>, both are included – thoughts? o Further discussion 4. If time allows, presentation of Group 2 – ICANN-approved transfers recommendations and any feedback received 5. AOB