Dear TPR WG members,

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

The next meeting will be on Tuesday, 30 May at 1600 UTC.

Best regards,

Emily, Julie, Berry, and Caitlin

ACTION ITEMS/HOMEWORK:  Re A possible registrant-initiated dispute resolution mechanism -- staff to present the use cases from IRTP-D for WG consideration; WG members to review and add use cases that might be missing.

Notes:

Transfer Policy Review - Meeting #92

Proposed Agenda

23 May 2023

1. Welcome and Chair Updates

• Looks like we will have pretty good availability among WG members in August, so we'll be going ahead and scheduling weekly meetings throughout August.
• Participation: We've been noticing that overall attendance on calls is declining and participation among the different represented groups is uneven.  Would be helpful to do a refresh of the membership and/or a self-evaluation survey to see how folks are doing and if they have feedback on how we can work better. Typically the refresh and the survey would happen around a key milestone, such as delivery of an Initial Report, but since that is some time off, this group might want to think about doing it sooner.  Reminder that the door is open and members/alternates can come to the chair or the staff at any time with feedback or suggestions on how to keep participation up (as well as anything else they want to share).
• Work Plan: A few session left before ICANN77 – focus on wrapping up our work on TDRP; next topic is ICANN-approved transfers.  No open action items at this time.

2. Recap Outcomes - Last Week’s Call – see attached slides 4-5.

f1) Is additional data needed to support evaluation of the effectiveness of the TEAC mechanism? If so, what data is needed?

Summary:

No new recommendations.

Respond to charter question by:

• Summarizing the data reviewed by the WG
• Identifying other types of information that would potentially support policy making in this group and in future  review
• Summarizing limits to obtaining and analyzing this information

f6/f7) The Transfer Policy Review Scoping Team indicated that there are several factors that make a Registry Operator’s obligation to  “undo” a transfer under Section 6.4 of the Transfer Policy challenging:

1. Registry Operators do not have access to the designated TEACs for each Registrar, making validation of an undo request nearly  impossible.
2. There is no way for Registry Operators to independently verify that a Registrar did not respond within the required time frame or  at all since Registry Operators are not a party to, or copied on, communications between the Registrar TEACs.
3. Transfer “undo” requests associated with the failure of a TEAC to respond are unilateral so there is no validation required prior to  a Registry Operator taking action. This has, on occasion, led to a “he said”, “she said” scenario.
4. Follow on to f6 iii., if the policy were to be updated to allow for some level of validation by the Registry Operator prior to taking  action, the requirement to “undo” a transfer within 5 calendar days of receiving an TEAC undo request leaves little to no time to  attempt to validate the request prior to taking the action.

To what extent are changes to the policy needed to address these concerns? Are there other pain points for Registry Operators that need  to be considered in the review of the policy in this regard?

Summary:

Item i: Policy staff is collecting additional information.

Item ii, iii, iv: Recommend no change. Response to charter question will summarize the deliberations.

Discussion:

• Re: item I – suggest “making validation of an undo request quite difficult” instead of “nearly impossible.”  Don’t want to suggest RO’s aren’t doing validation. Can’t change the charter question but in response we can note that nuance.

3. Charter Question g1 – see attached slides 7-8.  See also: https://docs.google.com/document/d/1i6tLO_qbSa-ace0BnKaAn7voP1UA1RjYlrRo2ZneZNY/edit?usp=sharing.

g1) Is there enough information available to determine if the TDRP is an effective mechanism for resolving disputes between registrars in  cases of alleged violations of the IRTP? If not, what additional information is needed to make this determination?

Additional Data Point: Forum reported that it received 11 TDRP filings in total, with 9 decisions and 2 withdrawals. 5 of the 9 decisions were filed prior  to December 1, 2016 when publication was first required.

To Discuss:

As a reminder, this question focuses specifically on whether there is enough information to evaluate if TDRP is an  effective mechanism for resolving disputes between registrars in cases of alleged violations of the IRTP. We will  discuss proposed recommendation to improve dispute resolution options as part of a different charter question  (g3).  Is it sufficient to answer this charter question but summarizing the information/data that the WG used to support its  deliberations on the TDRP, while noting that there are limitations to the available information about the broader  context of how issues are resolved (or not) using the available mechanisms?

Discussion:

• Question: We have info about the low number, but do we know why it is very low number of cases? Is it panel fee the reason? Answer: The dispute mechanism is efficiently looking at if someone broke the policy; a high-jacking typically doesn’t break the policy itself – the bigger issues are outside of the policy.
• Hope that registrars could give some input on this (why number of cases are so low).
• In answering the charter question we’ll say that we did have some data and decided we didn’t need any new policy recommendations.

4. Charter Question g2 – see attached slide 9 and also: https://www.icann.org/resources/pages/tdrp-2016-06-01-en, section 3 Dispute Procedures, 3.1 Registrar files a Request for Enforcement with a Dispute Resolution Provider, and 3.2 The Respondent shall have seven (7) calendar days from receipt of the Complaint to prepare a Response to the Complaint ("Response").

g2) The ADNDRC reported to the IRTP Part D Working Group that in some of the cases it processed, appellees and appellants failed to  provide sufficient information to support arbitration. Is this an issue that needs to be examined further in the context of the policy?

Are the existing informational materials about the TDRP sufficient to ensure that registrars understand the process and the requirements  for filing a dispute, including the information they need to give to the dispute resolution provider?

Discussion questions:

• Is the information in the policy clear? Does it need to be adjusted?
• As noted above, adjustments are expected following conversation of Rec. 27

Re: Rec 27 see the working document for rec 27, wave 1 for TEAC and TDRP: https://docs.google.com/document/d/1GTtkEPJvYNMW27UaJZAGQlSb1BOYRhO7rSbFyb_9dhs/edit

5. 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.

[Notes from TPR Meeting on 25 April 2023: Some members of the WG noted that TDRP section 3.2.4 could be stated at a higher level to ask the Panel to review the documentation provided to determine whether a violation of the Transfer Policy has occurred. Support Staff has proposed updated language on what this could look like.

Other WG members noted that the Panel should request the redacted registration data from the Gaining Registrar, similar to how this is done in a UDRP proceeding. Support Staff has also proposed language so that the WG could see how this could look.]

Discussion:

• There’s no requirement that the responding registrar must respond to the proceeding.  So no compliance issue.  It would be more effective to have the UDRP-type approach – would be a compliance breech if the registrar didn’t respond – best way to do this would be through the UDRP-style verification process.
• Leaning toward a UDRP-type of process would be more consistent – it works for UDRP and should work here.
• Once the case law evolve the evidentiary evidence becomes clearer, but that hasn’t happened here.  Can include that in the rationale.

This would be the suggested language from Transfer Dispute Resolution Policy with Rec. 27 updates at:  https://docs.google.com/document/d/12ncsCc_sYiBs2cRZVOPCrBes92aV0p-6S-7hNBkmM9w/edit

[[DRAFT ADDED STEP: The Provider shall submit a verification request to the sponsoring Registrar. The verification request will include a request to Lock the domain name.]]

[[DRAFT ADDED STEP: Within two (2) business days of receiving the Provider's verification request, the sponsoring Registrar shall provide the information requested in the verification request and confirm that a Lock of the domain name has been applied. The Lock shall remain in place through the remaining Pendency of the TDRP proceeding.]]

5. Charter Question g3 (time permitting) – see attached slides 10, 11, and 12.

g3) If the TDRP is considered to be insufficient:

1. Are additional mechanisms needed to supplement the TDRP?
2. Should the approach to the TDRP itself be reconsidered?

To Discuss:

Is there evidence to support that there is a problem to solve? For example evidence of the following:

• Frequent instances of registrants asking registrars to file TDRP cases, and registrars refusing to do so due to  time and cost, despite compelling evidence supporting the registrant’s case?
• Frequent instances of attempts at informal resolution where there is compelling evidence of an improper  transfer, but the Gaining Registrar is refusing to reverse the transfer absent indemnification, resulting in an  unsatisfactory outcome?
• Frequent instances of registrants reporting to registrars that they cannot access a court of mutual jurisdiction  to address stolen domains and/or improper transfers?
• Other examples of significant issues that may give rise to discussing a registrant option further?

If there is evidence to support that there is a problem, is a new dispute resolution process the best solution?

• For example, if the working group believes that domain name hijacking is a significant problem that is not  being addressed sufficiently, could the need be met by focusing on protections to prevent improper

inter-registrant and inter-registrar transfers from occurring?

As a reminder:

• The IRTP Part D recommended not to develop dispute options for registrants.
• The working group must provide a clear rationale if it believes that further work is needed on this issue.

Discussion:

• Zak: Thought the reason the WG didn’t want to recommend a registrant-initiated dispute resolution process is because it is out of scope of the current policy; but we can note that there has been considerable support for such a process so the GNSO Council should seriously consider it.
• Berry, staff: What would it look like if this WG were to recommend further work to be done: 1) Issue Report; 2) scoped into a PDP, etc. If this issue were to be deliberated further it boils down to whether there is an arbitration-type option because we already have the courts as an option.  If a policy were recommended to create a dispute mechanism for registrants, it’s not clear how it could be enforced since ICANN only has contractual relationships with contracted parties; how would you compel registrants to use it?  Or would it be optional?  Came up as an issue and was considered by IRTP-D without a recommendation. Not sure how we can draw a bright line between dispute about the transfer and the ownership of the name.
• Zak: If the WG were to make a recommendation, the WG can punt any determinations to the GNSO Council.
• Roger: We can’t just throw anything to Council, we have to have a rationale.
• Berry, staff: The WG does need to provide sufficient rationale to assist the Council in it making a decision to request an Issue Report and the resources to do it.
• Emily, staff: We’ve heard a call for a registrant-initiated process for TDRP disputes; the other is ownership disputes that don’t have anything to do with the transfer policy, which potentially hinges on who is best qualified to determine ownership – helpful to make sure cases can be successful.  Would it be helpful for this group to scope out the specific use cases that they think need to be addressed?
• It could be both a TDRP dispute and an ownership dispute.  Registrars should support this.
• We would need to document the use cases; we could start with the use cases from the IRTP-D.
• Emily, staff: Wonder if we want to revisit the use cases from IRTP-D and whether there are additional cases.  Also come back to high-jacking as a key use case and see if it is less of an issue today.
• Heard from registrars that high-jacking is not a big as issue as it used to be, but it still a big part of disputes.
• Berry, staff: Could be general support for some kind of recommendation to go back to the Council; in terms of providing substance around the recommendation – assuming Council signs off on an Issue Report, not sure staff has the expertise to produce one: Question to Zak – can you find suggestions of who or what organization that could help draft an Issue Report and also it would be interested to hear views of why groups would use the procedure; Question to registrars: Would they be willing to have one-on-one interviews with an independent researcher?
• Zak: No need for an independent researcher, can ask about level of interest in the public comment.
• Steiner: Is it correct that this WG doesn’t have standing to create a recommendation for a registrant-initiated dispute resolution process? Answer: There was not support for the current Transfer Dispute Policy being expand but for creating something new.
• Support handling this in a different group.

ACTION ITEM: Re: A possible registrant-initiated dispute resolution mechanism -- staff to present the use cases from IRTP-D for WG consideration; WG members to review and add use cases that might be missing.

6. AOB