Dear TPR WG members,

Please find below the brief notes and action items from today’s meeting. 

The next meeting will be a week from today on Tuesday, 10 October at 1600 UTC.

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 updates and provide feedback by COB Monday, 09 Oct

Transfer Policy Review - Meeting #106

Proposed Agenda

03 October 2023

1. Welcome and Chair updates

2. Continued discussion of Charter Question i1 (Full Portfolio Transfers AKA Bulk Transfers) and Charter Question i2 (Change of Sponsorship AKA Partial Bulk Transfers)

Recap of 26 September meeting:

The different options for policy language can be found here: https://docs.google.com/document/d/1b0KIvhRyyO5QSEI4DB4vP78muKvqHneaXOZTcvIiBPQ/edit?usp=sharing [docs.google.com]

Option 0: Current language (status quo)

Option 1: remove reference to fees

Option 2: Remove Price Ceiling

Option 3: Retain price ceiling + add apportionment of fees among Registries

Option 4: Algorithm

• According to Survey [docs.google.com] responses, the most popular option was Option 3
  • Second most favorite was Option 4
• The majority of survey participants believed price ceiling is necessary (ceiling # is still undecided)
• WG tentatively agreed to include the 5 options as open questions during public comment
• WG discussed negative consequences of NOT waiving a fee for involuntary termination, there was tentative agreement to waive the fee in these limited circumstances.
• WG requested information of percentage of registries who are currently approved to offer BTAPPA

• WG to discuss if BTAPPA should be included in Transfer Policy or make recommended updates to BTAPPA boilerplate

Prelim Rec. xx.1: The Working Group recommends that upon satisfaction of the two conditions described in I.B.1.1 and I.B.1.2, Registry Operator(s) MUST make the necessary one-time changes in the Registry database. The Registry Operator(s) MAY charge the Gaining Registrar a fee for making the change; however, the total fee MUST NOT exceed USD $50,000.

Discussion:

• I don’t think we can come up with a magic number. Whatever number we throw out, there will be people who dispute it.

• I agree, I believe that these will be situationally appropriate as the scope will have such amazing variance each time. Some might be simple, some might be complex
• Should be framed as rather than setting the number, the WG is not changing the number (currently $50,000).

Prelim Rec. xx.2: The Working Group recommends that 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.

Discussion:

• The total maximum cost will be $50k, rather than in the current policy where it is $50k for each TLD that is over 50k names. Make it a 50k names limit. The total maximum cost would always be less than what it currently is.
• If the Registry Operator is required to identify how much it will cost to exact the transfer, there should be a way for them to communicate those costs, based on their time and materials required. Here we have a one-size-fits-all model that is inelegant.
• For context, Charter question i1 was added because there was concern that 50k fee causes challenges specifically in involuntary transfers. The WG has discussed this and tentatively decided to waive this fee in those circumstances. Discussion around apportionment and how the industry has changed is helpful, but if there is no disagreement with (and alternative for) the status quo, then the status quo would remain.

Prelim. Rec. xx.3: The Working Group recommends that If the full portfolio transfer involves multiple Registry Operators, and one or more affected Registry Operator 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.¹

Prelim. Rec. xx. 4: The Working Group recommends that following the completion of the transfer, the Registry Operator(s) MUST provide notice to ICANN that the transfer is complete, and the notice to ICANN MUST include the number of domain names transferred.

Prelim. Rec. xx.5: The Working Group recommends that following receipt of notices from all affected Registry Operators, ICANN MUST send a notice to affected Registry Operators with the reported numbers and corresponding percentages of domain names involved in the bulk transfer, e.g., 26% of names for .ABC and 74% of names for .DEF. The Registry Operators MAY then charge the Gaining Registrar a fee according to their schedule.

Prelim. Rec. xx.6: The Working Group recommends that the Registry Operator MAY waive the fee associated with effecting an ICANN-approved transfer; however, the Working Group recommends that in cases of involuntary bulk transfers, the Registry Operator MUST waive fees associated with affecting the transfer.

Discussion:

• We should clarify what is “voluntary” vs “involuntary”
  • What if a Registrar wanted to merge their accreditation without fees, and purposefully tries to lose their accreditation?
• Moving Prelim Rec #6 to #1 might make it clearer
• I agree, add to the beginning to note when they MAY waive fee and when they MUST waive fee

Clarifying question previously posed to participants:

Should the scope of voluntary bulk transfers, including partial bulk transfers, be expanded and/or made uniform across:

1. all registry operators (via an update to the Transfer Policy),

OR

2.       all registry operators who offer the BTAPPA (via recommended updates to the BTAPPA)

Following the previous WG call, Support Staff had the action item to determine how many Registry Operators are currently approved to offer BTAPPA, provided below:

Total Active gTLD Registries	505
Active gTLD Registries with BTAPPA	24
	4.75% of total

Total Active gTLDs	1148
Active gTLDs with BTAPPA	311
	27% of total

Discussion:

• Perhaps Registries meeting a certain threshold of domains (e.g. 25,000 DUMs) must add the BTAPPA? There are many Registries below that threshold number that may not need it.

• We'd like to see Registries enjoy that scale. Registries have annual fee floor, and at the point that they grow to where they'd hit the threshold to trigger their per-unit fee perhaps the BTAPPA would be required then? (related to their ICANN fees per TLD)
• We don’t know the future. Small ROs may see huge growth, it is unpredictable.
• Partial portfolio transfers are probably going to grow in scale, although currently it doesn’t happen too often.
  • Where that happens (in Transfer Policy or BTAPPA boilerplate) is still something we need to decide.

• Within the RSEP, there are fees connected to that service. Should we have something to say about the cost element or fee schedule of BTAPPA?
• The Registry group is discussing the BTAPPA question and should provide input

Preliminary Recommendation Agreement #1: 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 no less than 30 days 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.
* A notice MAY encompass multiple TLDs if a Registered Name Holder has registered domain names under more than one TLD and the same parameters apply to the transfers, i.e., the date of transfer, instructions, etc.

Discussion:

• I’m still concerned about the 30 day notification. It takes time for the registrant to read and understand the notice and find another Registrar. There is also concern about access to private information. If there is any flexibility to extend the number of days, it would be good.
  • If there is a specific number of days in mind please share.
• “No less than 30 days” what if they send it 6 months ahead? Everyone would forget at that point. Looking at the ERRP as an example, what about requiring they notify affected registrants “approximately” 30 days before the change?
• Other groups have raised the desire for consistency in these dates. I would like to give the registrant as much forward notice as possible. We may want room for this to be waived just in case, if there is not an availability of time before having to move.
• If it is not voluntary, there are reasons for wanting to move them quickly, so having a quick path (triage) could be beneficial.

Preliminary Recommendation Agreement #2*: For a change of sponsorship, the expiration dates of transferred registrations are not affected and, therefore, there are no ICANN fees. Once the change of sponsorship is complete, there is no grace period to reverse the transfer.
(*This recommendation would be included only if WG agrees BTAPPA should become part of the Transfer Policy.)

Discussion:
-      Do locks apply? If there is usually a post-transfer lock, and in this case there is not, I think that needs to be in the policy somewhere
-      We cover that in a recommendation later in this list

Preliminary Recommendation Agreement #3*: A Registry Operator must reject a change of sponsorship request if there is reasonable evidence that the change of sponsorship is being requested in order to avoid fees otherwise due to the Registry Operator or ICANN. A Registry Operator has discretion to reject a change of sponsorship request if a registrar with common ownership or management or both has already requested a change of sponsorship within the preceding six-month period. 
(*This recommendation would be included only if WG agrees BTAPPA should become part of the Transfer Policy.)

Discussion:
-    This is to avoid gaming of the mechanism. These transfers don’t come with a term extension.

Preliminary Recommendation Agreement #4: The Losing Registrar’s existing Registration Agreement with customers must permit the transfer of domain names in the event of the scenarios described in the Transfer Policy with respect to a change of sponsorship. Additionally, the Losing Registrar’s Registration Agreement must inform registrants that in the event of a change of sponsorship, the affected registrants will be deemed to have accepted the new registrar’s terms, unless the registrant transfers their domain name(s) to a different registrar prior to the change of sponsorship. 

Preliminary Recommendation Agreement #5: The Registry Operator MAY charge a fee for a change of sponsorship, but Registry Operators MUST provide notice to Registrars of any fees associated with a change of sponsorship upon request and prior to the initiation of the transfer. How Registry Operators choose to provide notice of fees will be up to the Registry to decide, i.e., password protected portal, website, written notice, etc.

Preliminary Recommendation Agreement #6: 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.

Discussion:

• For ICANN-approved transfers, I think we agree there should not be a 30-day lock.
• Agree we should not apply the post-transfer lock as it’s not registrant-initiated
• If the domain is on ClientTransferProhibited status because the RNH requested it, that should carry over through the change
• Should be that the statuses do not change and no new locks are applied
• Also want to clarify that there is no ICANN-approval in BTAPPA transfer. ICANN approves the RO offering the service, but does not approve individual BTAPPA migrations when they occur once BTAPPA is available

Conclusion of meeting