Dear TPR WG members, Please find below the brief notes and action items from yesterday’s ICANN80 session on TPR. The next meeting will take place on Tuesday 25 June 2024 at 16:00 UTC. Kind regards, Christian, Caitlin, Berry, Julie and Feodora ICANN80 TPR WG Meeting 11 June 2024 Main discussion and Action Items Documents: TPR WG ICANN80 Session Slides<https://docs.google.com/presentation/d/1uFh08XvAW-Y5aEzFBwOsGYxuk6XWoATuGPaT...> Transfer Policy Review Working Group Draft Recommendations for Initial Report<https://docs.google.com/document/d/1xUJMqgb096HXIJ6xWNpNC_w5g6TukZxIbcN7_PTn...> AI: WG members that could not attend the ICANN80 session are strongly encouraged to listen to the recording of this session. AI: RrSG to provide exact wording to be added to Rec 5.3. Provide language for requested instructions. AI: ICANN Org to reconsider word “necessary” in proposed update. AI: ICANN Org to move the entire text of 19.1 to Rec 19. 19.2 becomes 19.1 AI: ICANN Org to move ahead and cross I.A.3.8.5 off and add rationale why it was removed. AI: WG to move ahead with proposed update as seen in slide no. 13. AI: ICANN Org to move ahead and add additional language to 25.1 (see above) and add wording for 25.3 (see above). AI: WG to move ahead and keep the proposed update language for Rec 5. AI: RrSG to provide specific language for the proposed update for Rec 26. AI: ICANN Org to keep new reordering but old numbers should be referenced in the table for reference. AI: ICANN Org will reach out to WG members individually where Recs need to be made more “digestible” for the initial report. Agenda: 1. Welcome and Chair Updates * There is no meeting on the 18th of June * Aim is to finish the initial report by the end of July 1. Review of outstanding recommendations following review period * Presentation of “cannot live with” recommendations * Rec 5.3 Registrar Stakeholder Group * Proposed Update: Instructions detailing how the RNH can take action if the transfer was invalid (how to initiate a reversal) and any deadlines by which the RNH must take action. 4.2. Instructions detailing how the RNH can take action if the request is invalid (how to invalidate the TAC) * 27.2 Instructions detailing how the registrant can take action if the change was invalid (how to initiate a reversal) AI: RrSG to provide exact wording to be added to Rec 5.3. Provide the above requested instructions. ii. Rec 22 Registrar Stakeholder Group · Proposed Update: Rec 22 A domain name is within 60 30 days (…) · [Rec 19 or 19.1: However, the working group recognizes that there may be situations where early removal of the 30-day restriction described in Recommendation 19 is necessary.] AI: ICANN Org to reconsider word “necessary” in proposed update. AI: ICANN Org to move the entire text of 19.1 to Rec 19. 19.2 becomes 19.1 iii. Rec 23 Registrar Stakeholder Group · Proposed Update: I.A.3.8.5 should be removed as there is no longer a lock associated with the CoR · Rationale: The Working Group is not proposing any revisions at this time. Per the working group charter, Change of Registrant will be addressed in Phase 1(b) of the PDP. The working group will revisit I.A.3.8.5 once it has completed deliberations on Change of Registrant. AI: ICANN Org to move ahead and cross I.A.3.8.5 off and add rationale why it was removed. iv. Rec 24 Registrar Stakeholder Group · Proposed Update: Clarification needed about auto renewal refunds to losing registrar from registry and/or to registrant from losing registrar. · WG members raised concerns that this might be outside the policy scope. AI: WG to move ahead with proposed update as seen in slide no. 13. b. Side comment on Rec 25.3 by Registrar Stakeholder Group * Proposed update: Can ensure clarification where the P/P email address differs from the RNH and the P/P furnished email address, so that we can identify which prevails. As I read this, changing P/P where the email address changes might trigger 25.1, but does 25.3 override that? I could see some Rr interpreting this as yes, some no. * 25.3: A “Change of Registrant Data” does not apply to the addition or removal of Privacy/Proxy Service Provider (P/P) data in RDDS when such P/P services are provided by the Registrar or its Affiliates. * 25.1: Add “Subject to the language in 25.3” AI: ICANN Org to move ahead and add additional language to 25.1 (see above) and add wording for 25.3 (see above). c. CAN LIVE WITH but prefer this change * Rec 5 - RrSG · Proposed update: The policy states “The working group recommends that the Losing Registrar MUST send a “Notification of Transfer Completion” to the RNH without undue delay but no later than 24 hours after the transfer is completed. For the purposes of sending the notification, the Registrar of Record MUST use contact information as it was in the registration data at the time of the transfer request. AI: WG to move ahead and keep the proposed update language. ii. Rec 26 – RrSG · Proposed Update: Clarification that a new PDP is not required for the new Change of Registrant Data Policy AI: RrSG to provide specific language for the proposed update. d. Discussion of Recommendation Reordering * ICANN Org provided rationale and aim of rec reordering. * Rec reordering is inspired by swim lane diagram * Rec 1 to 19 have been reordered. * Reordering is also proposed based on the suggestions to adjust the initial report format and make it more digestible for the public comment phase. * WG agreed that the new order is more logical. * Concerns have been raised that it might be difficult to “connect the dots” in terms of following the historical development of the Recommendations. AI: ICANN Org to keep new reordering but old numbers should be referenced in the table for reference. 3. Presentation of High Impact Recommendations and their policy impact (High impact means that there is a substantive change to the original policy text.) 1. Rec 26: Removal of requirements to obtain confirmation from Prior and New Registrant. Rec 26.4. Removal of post-Change of Registrant Data transfer restriction (AKA 60-day lock). 2. Rec 27 and Rec 28: Read together with Recommendation 28, these two recommendations (Rec. 27 and Rec. 28) have a high impact, in that a mandatory notification is now a notification that registrants may opt out of. 3. Rec 33: The changes, or lack of changes, to the TDRP results in a low impact to the policy; however, the high indiciation denotes the potential future policy work in completing an Initial Report on the requested issues. 4. Rec 35 to Rec 38: The recommendation, in combination with Recommendations 36-38 introduces the idea of a collective fee and various requirements associated with this new calculus. Specifically, rather than a threshold of 50,000 PER TLD, this involves a threshold of 50,000 across all TLDs, which significantly increases the amount of full portfolio transfers where fees are involved. Additionally, these recommendations create new coordination requirements for registrars, registries, and ICANN org. 5. Rec 40: New requirement to some registries who do not currently offer BTAPPA. 6. Rec 41: This recommendation involves a significant expansion of the BTAPPA service. AI: ICANN Org will reach out to WG members individually where Recs need to be made more “digestible” for the initial report. 1. AOB Feodora Hamza Policy Development Support Manager (GNSO) Internet Corporation for Assigned Names and Numbers (ICANN) Mobile: +32 496 30 24 15 Email: feodora.hamza@icann.org<mailto:feodora.hamza@icann.org> Website: www.icann.org<http://www.icann.org>