Dear TPR WG members, Please find below the brief notes and action items from today’s meeting. The next meeting will be during ICANN78 in Hamburg, on Saturday 21 October at 08:30 UTC (10:30 local time) Kind regards, Christian, Caitlin, Berry and Julie ACTION ITEMS/HOMEWORK: 1. Staff to update the draft recommendations based on today’s discussion 2. WG members to review the updated recommendations and provide any feedback by COB Tuesday, 17 Oct Transfer Policy Review - Meeting #107 Proposed Agenda 10 October 2023 1. Welcome and Chair updates * We will not have our usual Tuesday meeting next week. * Our next meeting will be in Hamburg for ICANN78, at 10:30 local time, Saturday 21 October. * Ken Herman (NCSG): I have had consultations with the Non-Commercial community regarding the 30 day notification. 6 weeks (calendar days) is the preferred length of time for our community. * We will revisit that recommendation again for WG discussion. * Jim Galvin (RySG): I have had consultations with RySG regarding the two ICANN-Approved Transfer charter questions. The RySG would prefer to leave the policy as is, but with two updates: 1. The trigger for bulk transfer fee should remain at 50,000 domains, but based on the number of domains leaving the Registrar, not going into the Registry. The apportioning of the fee should be based on the number of domains going into each Registry. 2. Regarding BTAPPA scope being expanded or made uniform, the current preference is to remain as is. Given that BTAPPA is currently a fast-track RSEP, the RySg is open to considering additional uniformity around that. * We have been focussing on portfolio transfers involving a single RO, but that is not common. There are usually several ROs, so I agree with the approach of considering all ROs and basing totals on a per Registrar basis. Will need to discuss more with Registrar colleagues. * There is another minor BTAPPA wording change ROs would like to see around “merger” or “acquisition”. 2. Continued discussion of Charter Question i1 (Full Portfolio Transfers AKA Bulk Transfers) and Charter Question i2 (Change of Sponsorship AKA Partial Bulk Transfers) Discussion of updated recommendations [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1_T41SQAH3duIPS9qhYE71iM5CAxpA3KUpgy55DK3Y3k/edit?usp=sharing__;!!PtGJab4!7LpdA4VxM1u3T25HsA_JlMudIptOmFyIrg_Gb2uYv9hKRUS2sfTsifcd9NhF6V6oh9l3oBhA_chhMl2TCmPThosC7q0nPsrWeOD0$> (updated as a result of last week’s meeting): i1) In light of these challenges described in section 3.1.7.2 of the Final Issue Report [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/file/field-file-attach/final-issue-report-pdp-transfer-policy-review-12jan21-en.pdf__;!!PtGJab4!5h-Zyrw8fPsFljPeSg8zw8BKHqFfHUIQiWid5x8U-ordaDclUcMt1HIw3uA-BrKiWjwR86Xx-VmCUtTPpII8CNlD4Kb78TDkXTSOLlU$>, should the required fee in Section I.B.2 of the Transfer Policy<https://www.icann.org/resources/pages/transfer-policy-2016-06-01-en> be revisited or removed in certain circumstances? Full Portfolio Transfers Prelim Rec. #xx.1: (i) The Working Group recommends that a Registry Operator MAY charge a fee to implement a full domain name portfolio transfer of 50,000 or more domain names from one ICANN-accredited registrar to another ICANN-accredited registrar, provided the conditions described in sections I.B.1.1 and I.B.1.2 are satisfied. (ii) The Registry MAY waive the fee associated with full portfolio transfers; however, in full portfolio transfers resulting from an involuntary registrar termination, i.e., where a registrar is terminated by ICANN due to non-compliance with the Registrar Accreditation Agreement, the Working Group recommends the Registry MUST waive any fee associated with a full portfolio transfer. Discussion: * The text says “from one ICANN-accredited registrar to another ICANN-accredited registrar”; does this allow for it to be split among multiple ICANN-accredited registrars? * Overwhelming preference is to move all domains to one Registrar, but there may be an instance where a Registrar does not offer all the relevant TLDs, so domains would need to be split among Registrars. * I think that it’s happened... but a registry only experiences one full transfer. I’ve never seen a registrar’s per-TLD portfolio being split * It could be hard to find a registrar that is accredited for ALL TLDs in the future * ICANN pays attention early to which gTLDs a registrar is accredited when considering the termination process and the Compliance breach process Prelim. Rec. #xx.2: The Working Group recommends retaining both (i) the current minimum number of domain names that trigger the fee at 50,000 names and (ii) the current price ceiling of USD $50,000. If the full portfolio transfer involves multiple Registry Operators, 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. Discussion: * I am confused how this is going to work unless ICANN gets involved earlier. * There are two kinds of full portfolio transfers: voluntary and involuntary. With voluntary portfolio transfers, if it is greater than 50,000 names then you can charge, that will be apportioned. We are changing the way that $50,000 limit works, so it doesn't go to any one Registry, it gets apportioned. And still the Registry MAY charge the fee. * The “notice” is that if there are more than 50,000 names, the registrar could pay up to $50,000. Partial Portfolio Transfers Prelim. Rec. #xx.1: The Working Group recommends that [the standard Bulk Transfer After Partial Portfolio Acquisition (BTAPPA)] be expanded to include circumstances where an agent of the Registrar, such as a Reseller or service provider, elects to transfer its portfolio of domain names to a new gaining registrar, and the registration agreement explicitly permits the transfer. Discussion: * Question: is that the Losing Registrar’s registration agreement or the Gaining Registrar’s? If it is the Losing Registrar, that could be a problem. * I believe that it would be the Losing Registrar. * The Gaining and Losing Registrar usually come to an agreement. BTAPPA was conceived as a partial portfolio from the Losing Registrar, so it is different. The RO isn’t checking, the Registrars would be making sure the notifications and agreements are completed, then they communicate to the RO. * In contracts there is already an advance consent of the registrant. Similar to the Designated Agent and resellers. But BTAPPA is not offered everywhere, so it needs to be allowed whether going in or out. * The registration agreement (of the Losing Registrar) has to explicitly allow this so the registrant is aware this can happen to them. * The IRT may be confused by the current language. We need to be very precise and specific with this text. Currently, do the agreements not prohibit transfers or do transfers need to be explicitly permitted? * They may not be prohibited, but having it allows registrant to be more informed. * I believe the language “agent of the Registrar, such as a Reseller or service provider” should be put on the registrant, i.e. as an “agent of the registrant”. * A reseller can be both the agent of the Registrar and the registrant. * This change of sponsorship is not initiated by the registrant, why the need to add registrant into this? * Staff understanding was that if a reseller wants to change Registrar it must transfer the domains manually one-by-one, and that this WG wanted the BTAPPA to be expanded to allow this to happen in a bulk scenario, which is not currently allowed in BTAPPA. If this is not the intention, please let us know. * The current fast-track wording implies the RO is not allowed to do a BTAPPA unless there is a merger, acquisition, or similar. The concern is that even though the involved registrar/registry is agreeable, they may be running afoul of the RSEP. We want the boilerplate language to allow agreeable actors to do what they want to do in the RSEP. * We have done BTAPPAs before where we signed an agreement with the Losing Registrar that we would buy the right to manage the portfolio, therefore it was a portfolio acquisition and was granted by the registry. That is a scenario we have done in the past, but that might not always fit or be possible. * As to the language, I would probably just expand on it where it says, where an agent of the registrant, such as the reseller service provider “acting under the authority or on behalf of the registrant”, elects to transfer… * I would be hard pressed to lose the last line, but I think we should make sure that it has language that basically states that this is the portfolio managed by an agent/service provider of the registrar losing those domain names, and is going to be transferred as a whole portfolio. Where previously only entire portfolios were able to be merged, this is a partial portfolio transfer for that registrar, but a full portfolio transfer for that reseller or agent. * Perhaps updating to “Agent of the Registrar OR registrant” to account for both scenarios? * Rec 1 looks good, just add some clearer language to it. Prelim. Rec. #xx.2: The Working Group recommends that in the event a change of sponsorship is permitted by the Registry Operator, Registrars shall either notify or ensure their Resellers (where applicable) notify affected Registrants approximately one month* before the change of sponsorship is expected to occur. This notification must provide instructions on (i) how to opt out (if applicable) (ii) how to transfer the name to a Registrar other than the Gaining Registrar [by x date] if desired], (iii) the expected date of the change of sponsorship, (iv) the name of the Gaining Registrar, and (v) a link to the Gaining Registrar’s (or their Reseller’s) terms of service * The WG recognizes that some flexibility is required in the timing of Change of Sponsorship (BTAPPA) notifications. As such, one month should be treated as no less than 26 and no more than 35 days. A registrar is not precluded from sending additional notifications earlier or later than this required one month notification. Discussion: * We would prefer no less than 30 calendar days, another 2 weeks would help. * To initiate a transfer, Registrars have to respond within a certain amount of time, also time for the registrant to read and understand it. * Current policy is 15 days, WG originally converged on expanding to 30 days to give more time and for consistency with other periods * These are voluntary negotiated transfers, so there doesn’t seem to be an urgency or emergency to reduce that time. Are there any objections to 45 days? * BTAPPA is not initiated by the registrant but the reseller or Registrar, there is no requirement to inform them and no change to the expiration date. Consider that when deciding the number of days. * One month makes sense but 45 days is too long. Many registrars will provide multiple notifications to remind them anyway. If the bare minimum is only 45 days, that is too far in advance. The registrant may forget or disregard because it is so far out. * My experience with resellers is the notification is sent and most people do not care, they did not choose their Registrar to begin with. Most people do not read this. * In many cases, the impact on the registrant is negligible. The notification will more likely cause confusion to the registrant. * Some non-commercial entities are concerned about where their domain sits, so they need to be alerted. * Let’s leave this as it is for now, but everyone give it some more thought. Prelim. Rec. #xx.7: In the case of a change of sponsorship, the Losing Registrar MAY have to prevent certain locked domain names from proceeding with the sponsorship change: specifically, names that are locked due to: (i) Pending UDRP proceeding that the Registrar has been notified of by the Provider in accordance with the UDRP Rules, (ii) a court order by a court of competent jurisdiction, (ii) a pending dispute under the Transfer Dispute Resolution Policy, or (iv) Pending URS proceeding or URS suspension that the Registrar has been notified of by the Provider in accordance with the URS Procedure. Rationale: The Working Group notes that the majority of domain name locks, including registrant-applied locks and EPP lock statuses, will remain in place following a change of sponsorship/BTAPPA scenario. However, domain names with locks applied as a result of the above specifically-named dispute proceedings/court orders involve jurisdictional challenges, and accordingly, will not be transferred to the Gaining Registrar. Discussion: * This reflects what we want but it may be an operational challenge to implement. * Aren’t they operational challenges today? Does this make it more challenging? * The law always supercedes the contract. We don’t need to make a list of all the things that may get in the way of this, we probably don’t need to say anything at all. * In current cases where Registrars are losing their accreditations, what happens to those domains that are mandated to be locked? * That issue is separate from this BTAPPA scenario. I think we remove the language listing all the caveats that we have to do already and instead focus on what we are trying to achieve with this rec; that there is no change to the locks or EPP statuses. * Perhaps a confirmation statement rather than a recommendation? Prelim. Rec. #xx.8: In the case of a change of sponsorship, the Gaining Registrar MUST NOT impose a new inter-registrar transfer lock preventing affected registrants from transferring their domains to another Registrar. Rationale: The Working Group notes that a change of sponsorship is not initiated by registrants and does not affect their domain name expiration dates; therefore, the transfer lock that would otherwise follow a typical inter-registrar transfer should not apply in this instance. Transfer locks that are triggered by other means set out in the Transfer Policy would still apply. Discussion: * No WG disagreement. * Continue to think about whether BTAPPA changes should be reflected in the boilerplate or Transfer Policy. * Staff will make small changes to the recommendations based on the conversation today. * Once they are updated, please review these recommendations again, if no comments are received by COB Tuesday, we will assume they are stable enough to be included in the Initial Report. Meeting concluded