Dear TPR Working Group members, Please find below the notes and action items from the meeting on Tuesday, 7 January 2025. Thank you. Best regards, Caitlin on behalf of the TPR Support Team -- Transfer Policy Review Working Group Meeting 7 January 2025 Action Items 1. 🚨🚨🚨 TPR WG members to identify any recommendations you CANNOT LIVE WITH in the TPR Final Report via the TPR WG Recs for Final Report Google Doc [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1vBi7kQFcCvsxL...> (due date: Monday, 13 January). 🚨🚨🚨 2. TPR WG members to consider the discussion of “Registry Family” from Recommendation 35 and provide suggested text in the yellow box here [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1YODFe-aZOi1AQ...> (due date: Monday, 13 January) 3. Registry representatives to socialize updated draft text from Recommendation 35 (available here [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1YODFe-aZOi1AQ...>) and provide feedback before or during the next meeting on Tuesday, 14 January. Notes 1. Welcome and Chair Updates * We will be using our next couple meetings to wrap up our Final Report. * Prior to the break, Support Staff sent a message to the WG, requesting all members to review the draft final recommendation text and record any “cannot live with” text by Monday, 13 January in the dedicated Google doc<https://docs.google.com/document/d/1vBi7kQFcCvsxLU6LA2E9IzH-DId1pIj3IAR2DXUK...>. Thank you to those who have already started this assignment. * Our Final Report is due to the GNSO Council the first week of February, so this is a very important period of review. * Our plan is to discuss and resolve the “cannot live with” text during our meeting on Tuesday, 14 February. * Thank you for all your work to date. We are almost finished. 2. Review proposed updates to Rec 35 * As a reminder, Recommendation 35 involves the fee associated with full portfolio transfers (bulk transfers). * During the public comment period, ICANN org noted the following, “this process as recommended presents difficulties for each of the parties in a bulk transfer (registrants, registrars, and even ROs who might be waiting for other ROs to respond before billing can be initiated). For ICANN org to play the recommended role in the billing and outreach of ROs adds complexity and inefficiency to the bulk transfer process.” * In recognition of this, Org suggested that there be a minimum threshold amount for domain names transferred to trigger the fee. * During the WG meeting on 17 December 2024, the WG discussed updated language drafted by Support Staff where highlighted text shows the proposed changes based on Org’s concern: * Recommendation #35 – Retainment of Current Full Portfolio Transfer Fee Ceiling and Minimum Domain Name Threshold The working group recommends retaining both (i) the current minimum number of domain names that trigger the fee at 50,000 names [per Registry or Registry Family] and (ii) the current price ceiling of USD $50,000. If the full portfolio transfer involves multiple Registry Operators [or Registry Families] [who transfer greater than 50,000 names], the affected Registry Operators MUST ensure the collective fee does not exceed the recommended ceiling of USD $50,000, and the fee MUST be apportioned based on the number of domain names transferred. [Implementation Guidance: Example 1: if Registry A transfers 55,000 names, and Registry B transfers 5,000 names, totaling 60,000 names, Registry A MAY charge up to $50,000, but Registry B cannot charge a fee. Example 2: If Registry A transfers 40,000 names, and Registry B transfers 20,000 names, totaling 60,000 names, neither Registry A nor Registry B may charge a fee, as neither registry meets the 50,000 name threshold. Example 3: If Registry A transfers 40,000 names, and Registry B transfers 20,000 names, totaling 60,000 names, AND Registry A and Registry B are in the same Registry Family, the Registry Family MAY charge up to $50,000.] * Note: the draft language includes the concept of a registry family due to previous concerns that one registry operator may not meet the threshold with one TLD but could with TLDs under the same Registry Family, which could warrant the payment of a fee. * The language also includes updated examples for when the fee could be charged/apportioned. Working Group Discussion Re: Price Ceiling * There is one example missing from the list - if there are two registries who are not part of a family and each has 50,000 names (totaling 100,000 names in the bulk transfer), wasn’t the idea to make sure each registry could only charge up to 25,000 – instead of both registries charging $50,000? * [YES - Action: Support Staff to add additional example to make this clear. COMPLETE - please see example 4 below.] * Example 4: If Registry A transfers 55,000 names, and Registry B transfers 55,000 names, totaling 110,000 names, Registry A MAY charge up to $25,000 (or 50% of the $50,000 fee), and Registry B MAY charge up to $25,000 (or 50% of the $50,000 fee), as each Registry transferred 50% of the total names.] * This seems very different from previous discussions - did we really mean to say that only registries that transfer 50,000 or more names can charge a fee? * This is indeed different from what was published in the Initial Report. These changes were based on public comments and ultimately represent what currently happens - in other words, registries who transfer less than 50,000 names cannot charge a fee under the current Transfer Policy. * Will need to check in with registries on this. * [ACTION: Registry representatives to socialize updated draft text from Recommendation 35 (available here [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1YODFe-aZOi1AQ...>) and provide feedback before or during the next meeting on Tuesday, 14 January.] Re: Registry Family * The WG should define what is meant by “Registry Family” as it is unclear whether this is regarding common ownership or common operation. * As an example, .VEGAS is a TLD who uses Identity Digital’s platform (Registry Service Provider). * .VEGAS has the same RSP as other Identity Digital TLDs but is not under common ownership. * In other words, is Registry Family a question of common operators or common owners? * What if there is a situation where an RSP decides to waive the fee, and a customer of the RSP would like to charge the fee? * If some registries waive their portion of the fee, it seems unjustifiable that other registries could increase their share of the fee based on others’ waiver. * Recommendation 36 deals with that precise question: The working group recommends that if the full portfolio transfer involves multiple Registry Operators, and one or more affected Registry Operators chooses to waive its portion of the collective fee, the remaining Registry Operators MUST NOT adjust their fees to a higher percentage due to another Registry Operator’s waiver. * There are three decision points based on this discussion: * 1. Trigger at which the fee is eligible, which seems clear * 2. Who gets to decide if you want to take the fee - the registry owner or the registry operator? * 3. Who decides how to apportion? Is it ICANN, or do registries work it out with the owner? * ICANN operates with Registry Operators and Registrars, not Registry Service Providers, and this needs to be operationally workable for ICANN. Adding RSPs to this calculus, when ICANN doesn’t have a contract with the RSP, may be making this messier. * We may want to stick with just registrars and registry operators and not introduce registry families to this recommendation. * [TPR WG members to consider the discussion of “Registry Family” from Recommendation 35 and provide suggested text in the yellow box here [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1YODFe-aZOi1AQ...> (due date: Monday, 13 January)] 3. Discuss Public Comment Review Tool (PCRT) notes/responses * Support Staff has completed populating the WG’s notes and responses to public comments in the PCRT<https://docs.google.com/document/d/1YODFe-aZOi1AQ3c8f2-y8MXtcUU4PjzsByFzk-dp...>. * WG members have the ability to edit anything they believe is not captured correctly. * Support Staff has been using the notes/responses in the PCRT to update the rationales provided in the Final Report. 4. Discuss Final Report * Support Staff has been converting the Initial Report into the draft Final Report. * All text that differs from the Initial Report will be highlighted in yellow so that it is easy to locate and review. * The yellow text in recommendations will have already been reviewed by the WG. * When the draft Final Report is distributed next week, WG members will be asked to concentrate on the updated rationales - in other words, the explanations highlighting when recommendations were updated to account for public comments received. * We are in a very important period of review as we have approximately three weeks to solidify the report. * The work is largely done, but please continue to complete your reviews and homework to ensure everyone is comfortable with the Final Report. 5. AOB