[GNSO-TPR] Notes and action items: TPR WG Meeting ICANN76 Session 1 - 11 March at 0900 EST

Julie Hedlund julie.hedlund at icann.org
Sat Mar 11 15:19:19 UTC 2023

Dear TPR WG members,

Please find below the brief notes and action items from today’s meeting.  Please refer to the recording and transcript for the formal record of the meeting.

The next meeting will be at ICANN76 with remote access:

Session 2: Sunday, 12 March at 10:30-12:00 Cancun (UTC-5) 15:30 UTC

Best regards,

Emily, Julie, Berry, and Caitlin

***The action items and notes are not meant to reflect a transcription of the meeting – refer to the recording and transcript for a formal record of the meeting***



Transfer Policy Review – ICANN76 Session 1

Proposed Agenda

11 March 2023

1. Introduction to the PDP and current topics under discussion

What is the Transfer Policy?

ICANN consensus policy governing the procedure and requirements for

registrants to transfer their domain names from one registrar to another.

  *   Goal: Enhanced domain name portability
     *   greater consumer and business choice
     *   registrants may select the registrar that offers the best services and price for their needs
  *   Went into effect on 12 November 2004
  *   GNSO reviewed the policy once before, shortly after implementation

Issue Areas for the PDP

Charter Topics:

Group 1(a):

  *   Form of Authorization (including Rec. 27, Wave 1 FOA issues)
  *   AuthInfo Codes
  *   Denying (NACKing) Transfers

Group 1(b):

  *   Change of Registrant (including Rec. 27, Wave 1 Change of Registrant issues)

Group 2:

  *   Transfer Emergency Action Contact
  *   Transfer Dispute Resolution Policy (including Rec. 27, Wave 1 TDRP issues)
  *   Reversing transfers
  *   ICANN-approved transfers


  *   Project plan originally anticipated a phased approach to the work, with deliverables for each  phase.
  *   Working Group produced a Phase 1A Initial Report, revised recommendations following public  comment on the report, and conducted preliminary deliberations on Phase 1B topics.
  *   Project plan was revised to account for newly-found dependencies between topics. The group  has consolidated work into a single phase, with an additional Initial Report planned covering  all topics and a single Final Report.
  *   Discussion of Phase 2 (now Group 2) topics began in February 2023.
  *   The working group will return to Group 1 topics after developing preliminary outputs on Group  2 topics to ensure that any dependencies are taken into account.

Transfer Emergency Action Contact (TEAC)

Registrars must establish a Transfer Emergency Action Contact ("TEAC") for  urgent communications relating to transfers. (Transfer Policy, Section I.4.6)

  *   May be designated as a telephone number or some other real-time  communication channel (Sec. I.4.6.1)
  *   Must generate a non-automated response by a human representative of  the Gaining Registrar (Sec. I.4.6.2)
  *   Responses are required within 4 hours, although final resolution of the  incident may take longer. (Sec. I.4.6.3)
  *   Channel is reserved for Rrs, Rys, and ICANN org (Sec. I.4.6.2)
  *   Records of communications for this channel must be retained and  documentation must be shared with ICANN and Rys upon request

Original Objectives of TEAC

  *   24 x 7 x 365 access to registrar technical support staff for  emergencies
  *   Quickly reverse instances of domain name hijacking or transfer  errors
  *   Ensure registrar representative is empowered to take action on  TEAC requests
  *   Policy violation for non-responsive registrars

Transfer Dispute Resolution Policy (TDRP)

  *   Designed for cases of invalid inter-registrar transfers, where  registrars are unable to resolve the issue amongst themselves
  *   Must be filed by Registrar (not Rt) within 12 months of invalid  transfer (TDRP Sec. 2.2)
  *   Decided by independent panelist(s) appointed by the Provider  (TDRP, Sec. 1.3)
  *   Complainant must pay fee to file a TDRP (may be transferred  to respondent in some instances) (TDRP, Sec. 3.3)
  *   Documentation of improper transfer is required (TDRP, Sec. 3.1, 3.2)

Update on Action Items for Staff:  Staff to research whether there are materials describing the goals of the TDRP.

  *   Regarding goals of the TDRP, here’s recommendation 26 from the 2003 Task Force Final Report: 26. That Registrars have access to a suitable process(es) by which they can dispute any specific transfers that they might object to after the fact (i.e. – a dispute resolution processes as outlined in the Reference Implementation described elsewhere in this report). And that such processes specifically include provisions that fulfill the following requirements. . .
  *   And here is an excerpt from the IRTP D Final Report about whether registrants should have direct access to file TDRP disputes: The Working Group discussed the issue of allowing registrants to initiate a TDRP, spending a significant amount of time on this issue. The Group went so far as to form a sub-team that drafted an amended version of the TDRP, which would allow for registrants to be able to initiate the process themselves. As part of its discussion, the Group developed a list of use cases that included scenarios under which registrants might initiate a transfer dispute (see Annex C).
  *   However, the WG decided eventually that the TDRP should not include dispute resolution options for registrants. Specifically, the WG was concerned that adding a new class of parties to an already complex and technical process would overload it. The WG also found it difficult to imagine how a ‘loser-pays’ TDRP cost-recovery scheme would work in situations where the dispute was between a legitimate registrant and a criminal. Therefore, it is preferable to create separate inter-registrant and inter-registrar transfer dispute-resolution processes and not to open the IRTP to registrant disputes.  https://archive.icann.org/en/gnso/transfers-tf/report-12feb03.htm

IRTP WG D Final Report for reference: https://gnso.icann.org/sites/default/files/filefield_46639/irtp-d-final-25sep14-en.pdf

2. Discussion of Charter Questions [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1i6tLO_qbSa-ace0BnKaAn7voP1UA1RjYlrRo2ZneZNY/edit?usp=sharing__;!!PtGJab4!-tRv2Ev3TOFqJqED6FtcTk30PcaaxszOfxMBakfcSR1FGGhyyAmnmkdZ8tzZpUMp0evZbEIWDsCXI6ezh-gqFbgVEwvDxLEb1g$> related to the Transfer Dispute Resolution Policy (TDRP)

Poll (Continued from 07 March):

Revised Q3: What do you believe is the main factor that results in the low number of TDRP filings?

  1.  Cost of filing a TDRP complaint (loser pays model) - 0%
  2.  Registrars work out the issue amongst themselves and do not resort to filing a TDRP – 13%
  3.  Length of time between filing and panel decision – 6%
  4.  All of the above – 56%
  5.  Not sure/no answer – 25%
  6.  Other – 0%


  *   One contributing factor to the TDRP not being used that much is because the registrant can’t be a party to the complaint, although the registrar can do it for them.

Q6. Are requirements for the processing of registration data, as specified in the TDRP, compliant with data protection law?

  1.  Yes – 37%
  2.  No – 5%
  3.  Not sure/no answer – 58%


  *   Looking at something that fits well but needs some adjustment.
  *   These polling questions aren’t a vote, but a way to test the temperature in the room and a way to start considering the charter questions. Also let staff know if there is information staff should be gathering to help consider the questions.

Q7. Based on the WG’s discussion to date, do you believe additional mechanisms (other than TEAC or TDRP) may be necessary to resolve improper transfers?

  1.  Yes – 55%
  2.  No – 18%
  3.  Not sure/no answer – 27%


  *   Opportunity to make some improvements or to fill in the gap with something else.

Charter Questions:

See: 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?


  *   Limited data available.
  *   Why there are so few cases – hard to say.  Some factors are cost, informal resolution, time it takes – and that registrar must file through a registrar.
  *   Need further fleshing out -- there was no clear agreement about whether additional reporting requirements may be appropriate.
  *   Should the dispute settlements between registrars be tracked?  Could be a reason for the low numbers of the use of the TDRP.
  *   Working Group members are encouraged to share any data they might have.

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?

i. 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?


  *   No extensive discussion of this question yet by the Working Group.
  *   Some requirements coming out of the IRTP.
  *   This is an important question – whether more information is needed.
  *   <COMMENT>This issue is related to the "change of registrant" issue. If the change of registrant process was more secure, there'd be fewer transfer disputes. That's why it's disappointing that the "push" mechanism I proposed in my public comments was not adopted by the working group, even as a parallel process to what exists now, for those who want it.</COMMENT>
  *   We will get back to change of registrant issues after we finish up with the dispute mechanisms.

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?


  *   Probably can’t answer this question until we finish discussions on TDRP.
  *   From the polling questions general sentiment was that changes were needed but not sure what.
  *   Different levels of effectiveness.
  *   Very few cases that have gone through the system.
  *   There is the question about what is the problem we are trying to solve.
  *   Focus areas: reducing the cost might reduce barriers to entry; introducing formality, such as accreditation; whether registrants are getting what they need – what current channels are available – settlement, courts (costly), through registrar (TDRP); some discussion of whether you can adjust the TDRP to accommodate registrants – but agreed that that would require either substantial changes or a new separate system.
  *   Talk about gaming or potential gaming is TDRP is available to registrants – could be adjusted for that.
  *   Big question: this WG is focusing and the TDRP as a policy – looking at issues of transfers between contracted parties, so disputes among registrants could be out of scope. Need to make sure we are staying within scope.
  *   Even if out of scope the WG could make a recommendation to Council that a process for registrants could be considered separately.

g4) Are requirements for the processing of registration data, as specified in the TDRP, compliant with data protection law?

g5) Are requirements for the processing of registration data, as specified in the TDRP, appropriate based on principles of privacy by design and data processing minimization?

Additional areas of discussion:  Statute of limitations: Is 12 months from the date of the alleged improper transfer an acceptable deadline to file a TDRP complaint?


  *   The polling questions covered g4 and g5.  Working Group members should review Sections 3.1.2 and 3.1.4 of the Transfer Dispute Resolution Policy for additional context on these questions.
  *   Question addressed in the polling but not in the charter questions – limitation on the time to file:  IRTP extended from 6 to 12 months.  In the polling some WG members thought it should be shorter, some longer, some thought it was okay.  So no clear direction for change.
  *   This is where gaming came up – once you set a data people will try to game.

3. Closing

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-tpr/attachments/20230311/05a6a163/attachment-0001.html>

More information about the GNSO-TPR mailing list