Dear TPR WG members,

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

The next meeting will be in two weeks on Tuesday, 07 November at 1600 UTC.

Kind regards,

Christian, Caitlin, Berry and Julie

ACTION ITEMS/HOMEWORK: Please review these recap materials in advance of our next call, so if there are questions or concerns you can bring them up during the call.  Recap materials will be distributed, covering the recommendations from WG Group 2, 1(a), and 1(b). The next call is on November 7. We also strongly encourage you to listen to the 17 January Zoom call before going into recommendation text and swimlane. 

Transfer Policy Review - Meeting at ICANN78

Proposed Agenda

21 October 2023

1. Welcome and Chair updates

1. Recommendations from ICANN-approved transfer (bulk transfers) are now in a stable condition. Been our focus since ICANN78. 
2. We will be briefly revisiting some open questions from other Group 2 topics before transitioning back to a recap of what the WG has agreed to date, and then moving to Group 1(b), which is Change of Registrant (Part II of the Transfer Policy) in November.
3. Working Group Member updates or Stakeholder updates – none.
4. Project Status (Berry, Staff)

• 5 weeks behind schedule wrapping up Group 2.
• We will do a recap of all groups before moving on.
• Total of 110 sessions (began Feb 2021), close to 1000 day duration, 165 hours of discussion time.
• Want to try to expedite moving through CoR, preferably go to Public Comment before June ICANN Meeting 2024, have Final Recommendation Report in May.

2. Transfer Dispute Resolution Policy (“TDRP”) – Registrant Access

1. Reminder of current draft recommendation

• Relevant charter question: g3) If the TDRP is considered to be insufficient: i. Are additional mechanisms needed to supplement the TDRP? ii. Should the approach to the TDRP itself be reconsidered?
• Current Draft Preliminary Recommendation:

The Working Group recommends the GNSO request an Issues Report or other suitable mechanism to further research and explore the pros and cons of (i) expanding the TDRP to registrant filers and (ii) creating a new standalone dispute resolution mechanism for registrants who wish to challenge improper transfers, including compromised and stolen domain names. In making this recommendation, the Working Group recognizes that if such an effort were ultimately adopted by the GNSO Council, this request could be resource-intensive and will require the Council to consider the appropriate timing and priority against other policy efforts.

2. ALAC message re: registrant access to TDRP:
   • View of the ALAC is that registrant should be given the opportunity to initiate TDRP, this should be included in the WG recommendations. This would not be for registrants to combat domain theft. It would still be under the conditions and requirements of the TDRP. The only option for registrants currently is to go to court.
   • The option of bringing legal option isn’t sufficient and is costly.
   • If no agreement in the WG ALAC will file a comment.
   • It is the responsibility of the Registrar to educate, guide, explain to the registrant.

• Options in light of ALAC feedback and previous discussion. When we introduced the topic earlier, we noted this was discussed/scoped by IRTP-D WG, they decided not to overload the TDRP. Potential options:

• Require registrar-provided rationale in the event registrar refuses to file TDRP.
• Registrant responsibility for TDRP fee.
• Open TDRP to registrant filers (where registrant is responsible for payment of fee, irrespective of outcome – similar to UDRP).
• Note: Need to ensure this is separate from other similar actions/processes.
• In this case, also similar to UDRP, the registrars would be responsible for registrar verification of data.
• Leave recommendation as is.
• Other Options?

Discussion:

• There are other policies that this may impact, e.g. ERRP. It is important to untangle that.

• Strongly think there needs to be a process, but need to investigate who the parties would be and what it would be – not the TDRP.

• Registries don’t think TDRP is the right mechanism – it is a very targeted process. From a registry perspective, concern that if TDRP is cracked open that it would not get worse. If rewritten, concern it would be expanded. Perhaps if there was another mechanism/tool.

• Should do something but should be separate/standalone and not UDRP.
• Registrars don’t initiate a TDRP but do so when registrant alerts them – should they provide a rationale if they don’t initiate.
• Before we go too far down the request for an Issue Report, need to consider other transfer issues – such as inter-registrant transfer – might want to wait until the WG discusses all related issues.
• From group 1a and 1b discussions, post-transfer restriction or policy issues out of Change of Registrant. The third option is on the table with current issue report recommendation, but the first two may be wanting more thoughts on this for an interim solution. It may be 3+ years until such a policy is enacted.
• Registrant could be confused by what it an inter-registrar transfer.
• Sounds like there is support for expanding (to bullet a.) If ALAC can provide comments during Public Comment that would be helpful  This group is not scoped to do this – is there something we can do as an interim solution – get feedback on these options::
  • Require registrar-provided rationale in the event registrar refuses to file TDRP
  • Allow the registrant to be responsible for any fee required by the TDRP provider
  • If the fee is set the registrant has the option to decide and can be well informed; still need to determine who would be the parties to the dispute. E.g. would it be filed against the Gaining Registrar, Losing Registrar, or gaining registrant? Whether that is TDRP or another vehicle.

Thoughts on the first two options in the interim?

• Don't believe ALAC has discussed fees on this, but if the registrant is informed of the fees they can weigh the pros and cons. The fee should be transferred and well-informed. 
• If we make a policy change that the registrant can pay the fee, my concern is the Registrar already knows that it will fail because the policy was followed.

• The one filing would be the customer/client of the former Registrar. Their ability to do anything is already diminished because they don’t have access.
• Maybe have a mechanism that is tied to getting domain back that is broader than just a failure of following the Transfer Policy. Registrants likely won't know the transfer policy well enough to know whether it was followed. We don't want registrants losing all the time.
• Always a bunch of lawyers involved. I doubt a registrant will pay without any legal backup. If the process is opaque maybe, but the registrant should advise legal counsel before filing TDRP.
• Leave the UDRP to trademark stuff.
• What about the first bullet? Registrars don’t typically initiate the TDRP on their own, the registrant contacts them and tells them something is wrong. Should we require a letter/rationale why they won’t pursue the TDRP. Maybe this is a course of action?

• Don’t think it's necessary. The panel should provide that data. If there is lack of support from the registrar, I don’t think the registrar will be willing to provide this data. 
• Think the current recommendation may eventually create a panel. Option 1 or 2 is something to do in the interim. Can we/should we add language to require Registrar to provide rationale in the interim?
• Two situations: when the person filing is mad their domain moved between registrars, or mad because they lost their domain. The TDRP is about: did you violate the policy? We need to consider the broader scope, there will be more discussions about this  when we talk about inter-registrant policy. Maybe before we start spinning work on this, we consider waiting until we discuss CoR. 
• If this is just an intra-registrar issue, that is something to think about.
• Introducing a new policy will likely delay our work and would be out of scope. ICANN Compliance already has a role, maybe we expand current language that would open a route for registrants to go through ICANN Compliance, enabling them to get more information they can use.
• If we are not careful, we will get into circular dependencies. Looking at Change of Registrant, when we did the high-level overview, the group had momentum about tearing down what is a Material Change for CoR. These were directly connected to what Rick was talking about re: disputes of CoR not change of Registrar. Maybe making a new mechanism could be a way forward in the meantime. 
• Change of Registrant may also be tangled with EDDP/ERRP. Need to be aware how a registrant could be confused about filing.

3. TDRP updates in light of EPDP – Temp Spec – Phases 1, Recommendation 27

1. Refresher of EPDP Team Recommendation #27. “The EPDP Team recommends that as part of the implementation of these policy recommendations, updates are made to the following existing policies / procedures, and any others that may have been omitted, to ensure consistency with these policy recommendations as, for example, a number of these refer to administrative and/or technical contact which will no longer be required data elements:

• Registry Registration Data Directory Services Consistent Labeling and Display Policy
• Thick WHOIS Transition Policy for .COM, .NET, .JOBS
• Rules for Uniform Domain Name Dispute Resolution Policy
• WHOIS Data Reminder Policy
• Transfer Policy
• Uniform Rapid Suspension System (URS) Rules
• Transfer Dispute Resolution Policy

2. Proposed updates to TDRP in light of Rec. 27 – see: https://docs.google.com/document/d/12ncsCc_sYiBs2cRZVOPCrBes92aV0p-6S-7hNBkmM9w/edit

Relevant Excerpt from ICANN Impact Paper: “TDRP section 3.2.4 provides that a panel appointed by a TDRP provider will “review all applicable documentation and compare registrant/contact data with that contained within the authoritative Whois database and reach a conclusion not later than thirty (30) days after receipt of Response.” This provision relies on comparison with the "authoritative Whois database," which does not have a clear analogue in the new Registration Data Policy.”

• ICANN Impact Paper notes:

o    Data could be requested by the panel (similar to UDRP), though that may result in duplicative data; OR

o    Requirements could be written at a higher level

o    In the current draft [docs.google.com], both are included – thoughts?

o     Further discussion

Discussion:

• TDRP / Rec 27. ICANN org delivered an impact policy that discussed what may need to be changed from EPDP Phase 1 recommendations. There is no clear analogue for “authoritative Whois database” in TDRP. Two potential options: (1) Data could be requested by the panel (like UDRP) but this may produce duplicative data; (2) Requirements could be written at a higher level. Both options were included in the current draft, but received no WG comments, so we wanted to make sure the WG is happy with the current recommendations.

• Sending the gaining FOA in no longer a requirement, so changes have been reflected
• Panel determines whether a violation of policy occurred based on the information provided. 
• We will send a link with this to make sure everyone is okay with this.

• Any comments on these? 
• Where does this data come from? Want to raise this as a potential challenge.
• There are evidentiary requirements the Registrar would be following, that is worth looking at.

4. If time allows, presentation of Group 2 – ICANN-approved transfers recommendations and any feedback received

Shortly after this meeting, the WG will receive a recap of where we are now. Support staff tried to highlight all the changes and draft recommendations thus far. We will distribute this recap document as well as updated swimlane. Since we have some time now, we will cover the recommendations from Group 2 (TEAC, TDRP, ICANN-approved Transfers). 

TEAC Recommendations: 

• TEAC Prelim Rec 1: The WG recommends updating the required timeframe for initial response from 4 hours to 24 hours / 1 calendar day.
• TEAC Prelim Rec 2: The WG recommends that the initial communication to a TEAC is expected to occur no more than 30 days following the alleged unauthorized loss of a domain.
• TEAC Prelim Rec 3: The WG recommends that substantive updates by email to the Losing Registrar occur at least every 3 calendar days until work to resolve the issue is complete. 
• TEAC Prelim Rec 4: Refers to the format of communication, and adding text around notification requirement that the initial email to the TEAC starts the clock.
• TEAC should there be a fast undo, clawback recommendation. A small team drafted a process, but the majority of the group seemed to think informal resolution works today. Adding to the Transfer Policy may add complications and so this mechanism was not added to the policy

TDRP Recommendations:

• TDRP Prelim Rec 1: The WG discussed opening TDRP to registrants, and recommended GNSO request an issue report to further look at these issues. 
• TDRP, Rec 27 - Prelim Rec 3 : textual changes to account for updated language in new policy

ICANN-Approved Transfers Recommendations

• Explanation of icons. Farm: a registrar is transferring all of its gTLDs to another registrar;  Herd: only transferring a particular TLD;  Single cow: partial portfolio transfers
• Prelim Rec 1: The RO MAY charge a fee, and MAY waive the fee

• It would be good to do some editorial work around the context of these recommendations. On the screen it says “Full domain name portfolio transfers”. Would be good to specify an “ICANN-approved full domain name portfolio transfer”. Once we publish these recommendations it should be very clear this is not BTAPPA. 

• Prelim Rec 2: Makes clear the number of names and price ceiling are staying the same, status quo. The ecosystem has changes since the policy was initially drafted, now there maybe many registries involved in a bulk transfer, look at recs 3-6 for allocation recommendations. 
• Prelim Rec 3: Due to the variable nature of the fee associated with full portfolio transfers, the WG recommends that ROs MUST provide notice to registrars of any fees associated with full portfolio transfers upon request.

• Due to Rec 2, we changed how this mechanism works. Now there is a hard cap on fees to Gaining Registrar. No fee schedule, it is fixed to cap $50,000. Given the way discussions have unfolded, I would suggest dropping Rec 3 as it may be burdensome/silly. There is no more schedule. If Rec 2 changes and the fee schedule becomes variable again then we can bring it back. 

• It says “variable nature of the fee”, but I guess the fee isn't variable now?

• You’re right the variable nature has disappeared, I think that is a good call to drop it. Do others disagree?

• Then Rec 4 may not be actionable. 

• Rec 4 I think still applies and can be used

• Registries are still good with Rec 4. 

• Prelim Rec 4: this notes that if a Registry decides to waive their fee, the others cannot charge more to bring the fee up to $50,000
• Prelim Rec 5: ROs would need to provide notice to ICANN with the number of domains transferred
• Prelim Rec 6: ICANN would send a notice to the ROs with reported numbers and corresponding percentages of domain names involved in the bulk transfer.

• “According to registrar’s fee schedule” is this language still appropriate?

• Prelim  Rec 7: the Gaining Registrar MUST be responsible for paying the relevant Registry’s fee (if any).

BTAPPA/Change of Sponsorship Recommendations

• Prelim Rec 1: Opening BTAPPA to include circumstances where a reseller/service provider wants to transfer its portfolio of domain names to a new Gaining Registrar
• Prelim Rec 2: WG recommendation to notify affected registrants approximately 1 month before the change of sponsorship is expected to occur.

• “by X date if desired” should that be before the transfer occurs? Let’s try to fill that in.

• To clarify ICANN does not approved BTAPPA, it is a service provided by the registry
• Prelim Rec 3: update to boilerplate BTAPPA language, confirming status quo that 
• Prelim Rec 4: RO must reject a change if there is evidence
• The WG has been talking about the macro changes, but we have recommendations on micro language. We haven't come to an agreement whether BTAPPA is going to be required or not.

• Either these recommendations go into BTAPPA boilerplate or they go into Transfer Policy. Where they will go is our only open question in bulk transfers, but the recs themselves still apply either way. 

So these are building block recommendations, like pre-preliminary recommendations?

• No matter where they go, these are our recommendations. The group agreed to these, but not yet to where they go

• Prelim Rec 5: Relevant agreements need to permit this type of transfer if using BTAPPA service
• Prelim Rec 6: RO MAY charge a fee for a change of sponsorship, but ROs MUST provide notice to Registrars of any fees associated with a change of sponsorship
• Prelim Rec 7: Notes that the gaining registrar must not impose a new inter-registrar transfer lock as this was not initiated by registrants

ACTION ITEM: Please review these recap materials in advance of our next call, so if there are questions or concerns you can bring them up during the call.  Recap materials will be distributed, covering the recommendations from WG Group 2, 1(a), and 1(b). The next call is on November 7. We also strongly encourage you to listen to the 17 January Zoom call before going into recommendation text and swimlane.