Dear TPR WG members,

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

The next meeting will be on Tuesday, 01 August at 1600 UTC.

Best regards,

Emily, Julie, Berry, and Caitlin

ACTION ITEMS/HOMEWORK:

Re: Charter Question i1 ICANN-Approved Transfer (Bulk Transfers) -- Staff will create a working document in Google for WG members to provide comments/suggestions.

Re: 1.B proposed updates: Staff will create a working document in Google for WG members to provide comments/suggestions.

Transfer Policy Review - Meeting #97

Proposed Agenda

25 July 2023

1. Welcome and Chair updates

Reminder that we do plan on continuing our work through August.
Steve Crocker, SSAC: Issue of smooth transfer of signed zones, raised but it was out of scope. SSAC is working on DS automation and glitch-free transfer – will send the wording to you and will brief groups when the report comes out.
Jothan: We shall always make best efforts on transfer of DNSSEC related _stuff_, but we frequently find this rather challenging when 3rd party DNS Providers are used.
Steinar: ALAC INPUT ON TRANSFER POLICY PDP CHARTER RECOMMENDATIONS PHASE 2 G3 will be distributed to the GNSO-TPR mailing list later this week. Apologies for being delayed a few days.

2. Discussion of Charter Question i1 ICANN-Approved Transfer (Bulk Transfers): See attached slides, starting with slide 17.

i1) In light of these challenges described in section 3.1.7.2 of the Final Issue Report [gnso.icann.org], should the required fee in Section I.B.2 of the Transfer Policy be revisited or removed in certain circumstances?

Recap of overarching themes from last call

The WG seemed to agree that in the event of an involuntary termination involving a bulk transfer, the mandatory bulk transfer fee should be waived.
Further discussion needed on future of mandatory bulk transfer fee
Language in Section I.B needs rethinking

Discussion:

Any discussion of gaming? That you could break them up into tranches of fewer than 50K to avoid a fee? Probably wouldn’t apply for portfolio transfers --- but will come up in other discussions.
Could also be voluntary registrar transfers. We need to be clear there.
Do we need clarity on what we mean by “bulk transfer”? We could think about whether there is better/more clear term?
Curious – it is the registry that loses $50K; are they willing to take these on? For involuntary is happens really infrequently.
In terms of the number of involuntary transfers over the last 5 years there were only two of them, but they do happen. The $50K fee is also for voluntary transfers as between registrars. In a voluntary setting, should there still be a $50K fee. See questions below.

ACTION ITEM: Re: Charter Question i1 ICANN-Approved Transfer (Bulk Transfers) -- Staff will create a working document in Google for WG members to provide comments/suggestions.

Potential options for mandatory fee

Should the mandatory fee be removed from the policy and left between Ry/Rr?
Should the mandatory fee be tiered based on volume rather than one lump sum?
Should the mandatory fee language remain as is?
Other options?

Discussion:

Not in favor of Rr/Ry agreements.
Comment: Agree with the notion that the fee was added to mitigate overuse seems odd. Looking at this as an overarching principle – why not come at this from the point of view there’s work for everyone involved, so if there’s a fee who should pay? Could be paid by whoever is motivating it? Separately, we could consider what that fee would look like.
When we talk about cost-recovery then the registrar would cover it as a flat fee. But registrar may also incur costs.
Two scenarios – voluntary and involuntary. Involuntary is good for the ecosystem. Who initiates an involuntary transfer? If it’s initiated by someone going out of business you won’t get a payment from that entity. Whatever scenario, registries and registrars will incur costs.
Maybe it isn’t fair for ICANN to pay if it is a problem that ICANN has discovered (involuntary scenario).
Even in an involuntary scenario you charge the registrar going out of business but you might not get anything.
Maybe the involuntary scenario is an exception.
Voluntary scenario: probably makes sense to include a fee paid by the registrar – flat fee, cost recovery? What does this language look like and how specific it should be.
Tiered approach: we don’t even know if that is even reasonable for a registry. Should be an option to bring a complaint about fees to ICANN Compliance.
By volume there is economy of scale – 10K isn’t 10 times the effort compared to 1K.
Cost recovery has concerns because registrars don’t know what to expect – whose checking this and how do you know it’s a reasonable fee?
Cost recovery policies are inherently troublesome. The U.S. government has imposed cost recovery policies on the operation of university computer centers. The results are terrible. The party asking for cost recovery has to justify the costs, which leads to both a lot of gaming and a lot of intrusive auditing.
This should be up front. It should be a process that the registry has figured out and knows what the cost is.
Should the policy say that registries should publish their fees? Why not?
So registries include in their RRAs for domain names – include bulk transfer fees? But how is this enforced? Do you have to tell ICANN your fee?
There needs to be a check and balance somewhere.
Starting to see some registries not putting fees in their RRAs, instead in web portals. Urge to have one fee structure across all gTLDs.
Registries and registrar will have different cost models.
Wonder if we can come up with a model, but that doesn’t have specific numbers?
Does the bulk transfer fee have to be mandatory – maybe build in exceptions?
Multiple TLDS – could be good if the transfer could be by organization on the registry services side. Also there are registrar families – could the fee be for the transfer process rather than by name/TLD?
Should the fee be left to the registry/registrar. Or could set a maximum.
It needs to be accountable. ICANN Compliance should be able to enforce.
Think we are focusing too much on a single registry operator. How this plays out across a number of TLDs.
Seems like we still want to be able to have flexibility in the fee assessment/amount and control an upper bound.

1.B proposed updates – see suggested language in brackets in slide 23.

Discussion:

The way that 1.B is currently worded is confusing.
On slide 22 – should be a 5^th bubble/bucket were the bulk is performed under standard EPP circumstances.
Currently the above scenario is not prohibited but might want to put parameters around it.
Not sure what you would achieve by including it in the policy.

ACTION ITEM: Re: 1.B proposed updates: Staff will create a working document in Google for WG members to provide comments/suggestions.

3. AOB