2023-08-08 Transfer Policy Review PDP WG Call

Notes/ Action Items

ACTION ITEMS/HOMEWORK: 

Any WG members who have comments or concerns regarding charter question i1 preliminary agreements please note them in the ICANN-Approved Transfers Working Document in advance of the next meeting.

Continue today’s discussion on the mailing list: Should there be locks, notices, and/or opt-out options for registrants?

1  Welcome and Chair updates

• On our last call, we transitioned from Charter question i1 to i2. The Working Document is available for comments and proposed edits to preliminary agreements. 

2. Review edits to preliminary agreements for Charter Question i1 ICANN-Approved Transfer (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?

3. Charter Question i2

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? (p.51)

a. Preliminary Agreements from last meeting – do these reflect what the Working Group discussed during the last meetings?

Potential expansion in BTAPPA or Transfer Policy:

[ (iii) 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 ]

Preliminary Agreement #1

The process should be transparent, and Registrants should be informed. [Registrars shall either notify or ensure their Resellers (where applicable) notify affected Registered Name Holders of the transfer (and allow opt out?)]

Preliminary Agreement #2

The expiration dates of transferred registrations are not affected and, therefore, there are no ICANN fees. Once the BTAPPA is complete, there is no grace period to reverse the transfer. (current text of BTAPPA)

Preliminary Agreement #3

Registry Operator must reject a BTAPPA request if there is reasonable evidence that a transfer under BTAPPA is being requested in order to avoid fees otherwise due to Registry Operator or ICANN. Registry Operator has discretion to reject a BTAPPA request if a registrar with common ownership or management or both has already requested BTAPPA service within the preceding six-month period. (current language of BTAPPA)

Preliminary 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/BTAPPA..

Preliminary Agreement #5

Registry Operator may charge a fee for a partial bulk transfer, but Registry Operators MUST provide notice to registrars of any fees associated with partial bulk transfers upon request and prior to the completion 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. (this language is a work in progress but attempts to characterize WG’s thoughts on full portfolio transfers)

PA#1:

• The Registrants have to be informed but cannot NACK the ICANN bulk transfers?
• (chat): Unless they opt out first
• Regarding PA#1 where the registrant may opt out. May be a situation where the Losing Rr needs to get rid of a domain, perhaps a notice period for registrants for a required gap time, during which they can transfer to the Rr of their choice, and if not in that time then it will be transferred in BTAPPA
• If there is an immediate transfer that happens, maybe the notice just has to cover “you can transfer after X day”. Expiration dates will not change. 
• There are situations where there isn’t always room for an opt-out.

PA#3:

• (chat): I am trying to determine how PA3 could provide the opportunity to dodge fees. where BTAPPA would not extend a domain term (ie Renewal)
• You are not avoiding fees, because every time you change you pay. There is no delay or avoiding of fees by continually switching Registrars. As a Gaining Registrar, you need to do your due diligence before entering this process, but it is business as usual for the RO as they will get paid either way. 
• What if the Losing Registrar has a balance due and they want to transfer the names to a Gaining Registrar, which does not take any responsibility for any previous fees, shouldn't the RO have a say?
• The Gaining Registrar might have some debt owed to the RO. Could have domains subject to auto-renew grace period, leaving a Registrar funding scenario that is problematic. Maybe language that says the RO has discretion to ascertain that.
• The question is what happens in the auto-renew situation. I believe the Losing Registrar gets refunded and the Gaining Registrar gets charged. With the transfer renewal not happening, that might cause issues. When the Rr is being told by ICANN that if the registrant doesn't pay the transfer fee cannot deny the transfer, this should similarly apply to ROs. 
• I would like to raise the macro question about why we are debating things related to Registry services unless we have already decided we are a BTAPPA requirement. It is out of scope to talk about modifying the BTAPPA only for those that use it. 
• If it is transfer related and we are making this ICANN-mandated policy then we should be able to talk about it.

PA#5:

• The expiry date remains intact, but the renewal is still coming at some point. We need to work on this a bit more. We don’t want anyone gaming the system, but eventually the bill will come due.

Discussion:

• Just to clarify: BTAPPA as it exists is a standard amendment language, but it is not TLD wide. An RO can request to have this in an RSEP process if it's not in their RA. 
• Yes BTAPPA is currently voluntary, but do we want to make it a policy in effect for everyone?
• Policy would make it uniform across ROs.
• we may want to include being able to bundle them, if you have a provider where there are multiple TLDs, like we now see TLDs bulked into RRA's

• (chat): ICANN Approved transfer: Still a x days transfer lock?
• (chat): the transfer lock is optional (e.g. “may”) and yes, can be applied as part of ICANN-approved transfer
• Could we talk about how other transfer requirements impact BTAPPA (e.g. NACK, locks)
• For transfers via BTAPPA or ICANN-approved transfer as there is not the same concern about security: provide an exemption for the lock. Some registrants do not want to move and are then unhappy being faced with a transfer lock, unable to move away
• When we talk about locks and statuses here, since there is not an actual transfer, the lock is unaffected. Need to make sure the UDRP and DNS Abuse issue domains are exempted from the bulk switch, and sorting those is the task of the Losing Registrar not the RO. 
• Yes this is not a true transfer in the normal sense. 
• (chat): Perhaps “change of sponsorship” is a better term in this situation?
• (chat): I think that's a brilliant name
• (chat): I like that suggestion
• (chat): there is also a lot of established expectation around "Transfer", such as the term extension of 1y and other stuff.  and this is not really a "Transfer" but more of a "Move" or "Change of Sponsorship”

• (chat): a transfer lock is a UDRP requirement, but also I use that lock for domains engaged in DNS Abuse since i do not want the criminals to move to another registrar, but the EPP code is the same.
• We have heard the Working Group note that language in Section I.B.2 should be clarified. Also note that these transfers do not require all of the same notices and requirements as a typical registrant-requested transfer.

• We should designate a number of domains for change of sponsorship. Domain name investors sometimes have thousands of domains. It is problematic to respond to 10,000 FOAs.
• (chat): Do we have some stats of the volume of BTAPPA “transfers”?

• The number is important especially if it becomes a policy. It is a painful manual process when the BTAPPA isn’t in effect.
• If a RO provides numbers (low) as there are high fees associated with the BTAPPA, but we made it more complex for resellers to transfer domains. I am for more security, but need to remember large portfolio holders will be impacted by the new Transfer Policy. We want Registrars to go for this option as they will have no other way out. I can reach out to the Dutch registry and ask about their numbers. 

• I like what they said that this is a change of sponsorship. BTAPPA is not about transfers, perhaps we change the vernacular. If it is not a transfer then locks and reversals don’t apply. I don’t think there is a golden number, and I don’t think there is a need when it is a change of sponsorship, and if the RO is able to set their own fees. 
• We are talking about changes of sponsorship without a term extension, and those fall into situations where there are required changes of sponsorship (non-elective situations) or elective situations where people are buying and selling registrations and resellers moving. There is no real difference between a reseller or domain investor moving, the only difference is volume. Any attempt to pick a number will be difficult. We seek this to be a voluntary service to allow ROs and Rrs to be competitive in their offering and demonstrate their commercial capabilities. 
• There may be some TLDs we get some statistics for. Right now, in agreements with registrants we can automatically transfer to Rr in lieu of a renewal. This might be broken by changes proposed elsewhere by the WG, this might make things harder. We could possibly implement across the span of a year rather than all at once. We will want to allow if there are Registrars in place where it is automated, that it is not broken. Keep those entities in mind as they may be affected.
• (chat): basically the BTAPPA is a way to consolidate a portion of a registrar at another one. this MOSTLY happens when registrars upgrade from reseller to direct RRA with a registry. but there are some registrars that utilize multiple creds for registrant intake and more robust experience / success in registration for their customer, who ultimately want to consolidate the registrations under a sole cred.
• I think a BTAPPA will be used more often if it is fair. Regarding the golden number, maybe a tiered approach.
• We should not conflate resellers, registrants, and domain investors. Registrants have rights that resellers cannot do. Resellers do not have rights under the RA. This is a problem given the reliance on resellers, I would urge we have a bulk transfer functionality for such providers so they can manage the domain name portfolios of their customers in the best way possible. 
• There are many registrants who just want a working domain name and service, they don’t care who makes it work. They know their reseller but not their Registrar, and that’s not necessarily a bad thing.
• We have to remember that the change of sponsorship does not necessarily change the service provider. I don’t understand any locks with a change of sponsorship; there is no additional fee for the expiry year, there should be no lock. The increase of volume of use for the BTAPPA, if it is made policy this may be affected by the fees set by the ROs.
• The fee should be a cost-price. I agree if a registrant isn’t pleased with the new Rr, there should be an opt-out. The reseller should announce that to their customers. The goal is to make this as smooth as possible for the registrant. 

• There is still the question of whether this is BTAPPA or Policy? We’ve raised some more questions and there are 3 weeks left. There is general agreement in this area but the details need to be worked through, probably on the list. 
• Remember this is not a fast process. It takes at least a month before every party is in sync. Not everything will change immediately and there are checks and balances in place.
• Most of the time the operations and technology folks are not the long pole, but the business side. Keep in mind when optimizing for speed.

• (chat): A key element is the notice periode (x days) where the RNH can opt-out from a ICANN change of sponsorship. This will be handled as a regular transfer
• (chat): I think they said it's 15 days, currently
• (chat): Maybe too short. In my view a minimum of 30 days
• (chat): I think so too, let's standardize at 30days  :)

• Should there be locks?
• The registrant shouldn't be affected by a change of sponsorship. So there should not be a lock following a BTAPPA or ICANN-initiated transfer. 
• There will be a light impact. They will get a notification and decide to go along with it or maybe opt-out.
• (chat): I'm OK with expiration date not changing, and with the domain lock not being applied
• I agree. Registrants don’t notice it except for a notification. I don’t think locks will be handy. Don’t want the situation where a reseller constantly changes Registrar, but those are probably edge cases. We can put in the BTAPPA or Policy that the RO tracks this was move #X within X amount of time, maybe impose limits.
• Good to think about. Also consider moves initiated by the registrant rather than by the reseller. 
• (chat): What is the likelihood of “reseller jumping” becoming a new business model…
• (chat): it is unlikely. BTAPPA's not likely to be a simple process that could fuel Reseller hopping. its a good question - I appreciate the quality of your questions Steinar

4. AOB