The call for the Transfer Policy Review PDP Working Group will take place on Tuesday, 29 August 2023 at 16:00 UTC for 90 minutes.

For other places see: https://tinyurl.com/3t832rnx

PROPOSED AGENDA


  1. Welcome and Chair updates
  2. Continue discussion ofPreliminary Agreements [docs.google.com]from Charter Question i1 (Full Portfolio Transfers AKA Bulk Transfers) and Charter Question i2 (Change of Sponsorship AKA Partial Bulk Transfers)

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?


i2) Should the scope of voluntary bulk transfers, including partial bulk transfers, be expanded and/or made uniform across all registry operators? If so, what types of rules and

considerations should govern voluntary bulk transfers and partial bulk transfers?

      3. AOB

BACKGROUND DOCUMENTS



PARTICIPATION

RECORDINGS


Audio Recording

Zoom Recording

GNSO transcripts are located on the GNSO Calendar

Notes/ Action Items


 

ACTION ITEMS/HOMEWORK:

  1. Staff to update the TPR Working Document based on today’s discussion, including the 5 questions posed during the call (Re: Concepts 3 & 4).
  2. Re: Charter Question i2) – WG members to provide their comments/suggestions in the Working Document regarding whether the scope of voluntary bulk transfers, including partial bulk transfers, should 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)

Notes:

1.  Welcome and Chair updates

  • Reminder that there will be no meeting next week
  • The next WG meeting will be 12 September 16:00 UTC

2. Continue discussion of Preliminary Agreements from Charter Question i1 (Full Portfolio Transfers AKA Bulk Transfers) and Charter Question i2 (Change of Sponsorship AKA Partial Bulk Transfers)


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

Preliminary Agreement #1: The Working Group recommends that a Registry Operators MAY charge a fee to implement a full domain name portfolio transfer* from one ICANN-accredited registrar to another ICANN-accredited registrar. The Working Group recognizes that there may be instances where the Registry Operator MAY waive this fee.**

  • * Note: this could include all of the domain names a registrar has within a gTLD or all of the gTLD domain names a registrar has under management.
  • ** A non-exhaustive list of examples where a Registry Operator may choose to waive the mandatory fee include cases where a registrar is involuntarily terminated by ICANN org due to a breach, ICANN terminates a registrar due to unresponsive to renewal notices, a registrar chooses to voluntarily cease operations with a specific TLD, etc. 

Discussion:

  • The middle example could be removed and keep first and last. 
  • The first two examples do seem to both be involuntary termination; I am not sure that we need both
  • Middle example can be kept but should be updated to read: “Unresponsive to accreditation renewal notices”, so it is not misconstrued as domain name renewal notices
  • No objections to updating second example to include “accreditation”


Proposed Preliminary Agreement #2:
The Working Group recommends that the Gaining Registrar MUST be responsible for paying the relevant Registry’s fee (if any). 

  • Rationale: The Working Group recognizes that a voluntary request to transition a domain name portfolio to another registrar will require internal coordination and work from the relevant Registry Operator, and accordingly, the Registry Operator may charge a fee for this process. Due to the voluntary nature of the portfolio transfer request, the Gaining Registrar should be responsible for paying this fee to the Registry Operator as (i) the Gaining Registrar, through the transfer, is inheriting new customers, and (ii) the Losing Registrar may be going out of business and, accordingly, may be unable to pay the fee.

Discussion:

  • No changes proposed

→ Concept 1:  The Working Group recognizes that a fee may be involved in a full portfolio transfer but believes flexibility is necessary, and the number should not be explicitly prescribed in the Transfer Policy.

→ Concept 2: The Working Group also recognizes, however, that a price ceiling is helpful to include in the policy language to avoid abusive pricing  in order to promote transparency in pricing.

→ Concept 3: In light of Concept 2, the Working Group believes the total fee for a full portfolio transfer must not exceed [$50,000 or $1.00 per domain name transferred].
Discussion:

  • Note that if there is no agreement, then the status quo remains
  • Concept 3 triggered the At-Large discussion on the CPWG mailing list. There was concern about the WG’s reference to fees, and that policy should not have specific numbers due to antitrust/competition concerns. There may be additional feedback coming from At-Large.
  • I do not think that antitrust concerns are something we need to necessarily consider in this group. ICANN was set up in consultation with antitrust experts and has a legal counsel that looks into these issues. The price for bulk transfers has been in the RA for a long time, and the RAA also has limits to what a registrar can charge for bulk access to registration data ($10k). So ICANN does in several instances specify costs, price caps, and fees. We can see if there are any public comments. If we have something we think works and is reasonable from a process perspective, we should pursue it. 
  • If we are not allowed to talk about the fees, does this mean the current fees ($50,000) will stay the same forever? Even if we opt to get rid of it, that could be an antitrust concern.


→ Concept 4: If the full portfolio transfer involves multiple registries, the affected registries must ensure the collective fee does not exceed the recommended ceiling, and the fee should be apportioned based on number of domain names. By way of example, if a registrar has 60,000 domains under management under two TLDs, e.g., 40,000 names under .ABC, and 20,000 names under .DEF, the combined fee cannot exceed $50,000 USD (per concept 3). Since two thirds of the names under management are registered to .ABC, .ABC registry may bill the GainingRegistrar for up to 66.66% of the total fee [of $50,000], e.g., up to $33,333.33, and .DEF may bill the Gaining Registrar for up to the remaining33.33% of the total fee [of $50,000], e.g., up to $16,666.67.

Discussion:

  • If one RO wants to waive their portion of the fee, does the other RO get to bill the registrar for the full $50,000? 
  • No, an RO (.DEF) should not benefit from another RO (.ABC) waiving the fee. 
  • Percentages would be presented up front. The numbers would not be adjusted based on who waived. We should make that more clear.
  • 5 questions posed for the WG to consider:
  1. Is $50,000 the number to be used? 
  2. In the current policy, there is a minimum number of domain names that are involved: is that still in play?
  3. Is there a minimum number of domain names that a registry has involved in order to qualify?
  4. If so, what is that minimum number of domain names? (e.g. is the registry allowed to bill for one domain name?)
  5. How would all this be handled? Would ICANN org need to be involved to help manage this process, and if so, why? 
  • We are using these numbers as examples (assume they are in brackets). Agree we need to decide are there bounds that we need to put? We should put the questions in the working document. 
  • It would be good to know in advance that Concept 4 is acceptable for the Registries. There may be different ideas of what is the “magic number”, though not everyone can be accommodated.
  • This could be difficult to administer without ICANN involved as an intermediary. From an RO perspective, not opposed to this concept but the whole mechanism not be worth the effort. It would be interesting to explore concepts around loosening/reducing fees here in exchange for more flexibility around BTAPPA. That may be a way to find common ground. 
  • I'm not sure we need a threshold number of domains if we have a limit (cap) on cost. It might be cheaper (compared to the cap amount) to do individual transfers but still worthwhile to have them done in bulk.
  • In my view there must be a calculation comparing ICANN approved transfers vs “regular transfers”, but the calculation is depending on the level of fee for the ICANN transfers
  • Is there any historical rationale behind the $50K? Unknown.
    • From the CPWG mailing list: The $50,000 fee set forth in the current ICANN policy document, was conceived during a time when ICANN regularly included pricing in their Registry Agreement.

ACTION ITEM: Preliminary Agreement #5, Concepts 3 & 4 – Staff to list the 5 questions posed during the call within the TPR Working Document. WG members to review and respond to these questions before their next meeting (12 September).


i2) Should the scope of voluntary bulk transfers, including partial bulk transfers, be expanded and/or made uniform across all registry operators? If so, what types of rules and considerations should govern voluntary bulk transfers and partial bulk transfers?

Poll Questions to WG:

1.  Do you support the scope of voluntary bulk transfer, including partial bulk transfer, being expanded and/or made uniform across all registry operators via an update to the Transfer Policy? (would apply to all registries)

Yes: 13 (72%)

No: 2 (11%)

Not Sure: 3 (17%)


2.  Do you support the scope of voluntary bulk transfer, including partial bulk transfer, being expanded and/or made uniform across all registry operators who offer the BTAPPA via recommended updates to the BTAPPA?

Yes: 11 (58%)

No: 3 (16%)

Not Sure: 5 (26%)


Discussion: 

  • This would only apply to all gTLD registries, not ccTLD registries
  • We are working on the assumption that we are allowing ROs to add flexibility to their fees
  • These polls are going to skew based upon group composition... so you will see things skew towards what registrars are thirsty for
  • With new gTLDs there is a wide volume of process and policies, BTAPPA is better for a wide scale of TLDs then just having policy. There may be scenarios where there are not that many domain names to qualify.
  • If we have a reseller with a TLD that only has 50 names, then it is not worth the time of getting a developer involved. Then we will try to do that as a normal transfer. It is always a cost balance exercise.
  • The choice to be able to do this manually will become more complex once the policy goes into effect and the TACs are in place. We have not yet discussed the possible inefficiencies when there are many TLDs bundled.
  • Going back to the threshold question, maybe it makes more sense here than in the icann-approved transfers discussion? If it's a full portfolio transfer then it doesn't matter how many domains there are, just that it's a full set. If it's a partial portfolio, then that's where the cost comes up (maybe there's only 200 domains total, then probably just pay one by one, right?)
  • In a sponsorship change, what impacts the registrant the most is that the expiration date is not changing, unlike a normal transfer.


Preliminary Agreement #1 (Change of Sponsorship) (AKA BTAPPA): 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 at least [30 days] before the change of sponsorship will occur [and provide opt out instructions where applicable].

Discussion:

  • Appreciate the focus on the registrant’s experience. Registrants should always be able to choose who their provider is. Not sure if we need “where applicable”.
  • Not objecting to the concept there should be notification, but this is redundant with an item from BTAPPA boilerplate language. However the [30 days] is different from the current boilerplate language of [15 days]. 
  • Agree we should not start from scratch, the question remains should this be optional or for all gTLD registries?
  • Important that a successful BTAPPA does not add any transfer lock for the registrant to select another Registrar


Preliminary Agreement #4 (Change of Sponsorship): 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, prior to initiating the transfer, the losing registrar must ensure that they, or their Resellers (where applicable), have confirmed the affected registrants have agreed to the terms.]

Discussion:

  • Previous comment: Isn’t it simply the responsibility of the gaining registrar? Not sure if this is a policy requirement. In the case of a reseller or other entity, it is up to them to make sure their agreements reflect or mirror the agreement with the new registrar.
  • I'm not sure this is necessary; I don’t think we can have registered domains where the RNH has *not* agreed to the Rr terms?
  • This needs to be done, but I don’t know if it should live in this Policy
  • Maybe in the notification to the RNH, “on X date your domain will be moved to X registrar and you will be subject to these terms of service: X.”
  • Practically speaking, confirming that they accepted the new terms is not going to work in reality. The notification though would be good.
  • The RNH is not bound to the terms just by notifying them, unless their registration agreement with the current registrar or reseller stipulates that.
  • Where and how is this going to be enforced? Do all registries have to by way of policy, or is this an optional service registries can provide?
  • Moving forward, it makes sense that registries operate under the same policy. If one registry uses BTAPPA but another does not, that is a barrier to transferring as a normal transfer of 20,000 domains can be expensive and inconvenient.
  • Remember that with the next round there will likely be many more new gTLDs
  • Some answers live in the BTAPPA boilerplate. Some registries might be reluctant to use it because there is no extension of expiration term. Better served if current BTAPPA wording is loosened so that if two registrars have a list of domains they agree they want to move without an extension, then they can do it. Right now it is more restrictive, so wording can possibly be improved.


ACTION ITEM: Charter Question i2) – WG members to provide their comments/suggestions in the Working Document regarding whether the scope of voluntary bulk transfers, including partial bulk transfers, should 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)

    3.  AOB



  • No labels