May 2023 - GNSO-TPR - lists.icann.org

Transfer Policy Review PDP WG
by ICANN Policy Calendar May 24, 2023

May 24, 2023

Meeting: Transfer Policy Review PDP WG Pattern: Weekly on Tuesday’s: 01 August – 29 August 2023 at 16:00 UTC for 90 minutes Alternate replacement confirmations – Members who are unable to attend, please complete the google form<https://docs.google.com/forms/d/e/1FAIpQLScXP3-H595xH4EFgaR3ydOr-1o9BLAVGUI…> to communicate who the alternate is replacing you. Join the Zoom Webinar: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 Passcode: @TP/^*4wg# ALL: Before joining the call: * Please send apologies and dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior<https://www.icann.org/resources/pages/expected-standards-2016-06-28-en> * Wiki agenda page (2023): https://community.icann.org/x/Gow-DQ * Time conversion link: https://tinyurl.com/ykevzvaw ONLY for Members & Alternates: * Please join via the above Zoom Webinar link and staff will promote you to Panelist * Alternate assignments will be posted to the Alternate Log-Transfer Policy Review PDP wiki page<https://community.icann.org/x/V4aUCQ>. * Members and alternates replacing members, please select Everyone when posting to the chat in order for everyone to see and to be captured afterwards. * Alternates (not replacing a member): Please rename your line in Zoom by adding THREE Zs “zzz” before your name, and in parentheses, (your affiliation - alternate), after your name. * Alternates (not replacing a member) are not allowed to engage in the chat or use any of the other zoom room functionalities such as raising hands or agreeing/disagreeing. ONLY for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. For Audio only: One tap mobile: US: +19294362866,,95363727469#,,,,*7490739013# or +13017158592,,95363727469#,,,,*7490739013# Webinar ID: 953 6372 7469 Passcode: 7490739013 International numbers available: https://icann.zoom.us/u/acdLFXPLp6

1 0

Notes and action items: TPR WG Meeting #92 - 23 May at 1600 UTC
by Julie Hedlund May 23, 2023

May 23, 2023

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-ace0BnKaAn7voP1UA1RjYlrRo2Zn…. 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_… 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-7hNBk… [[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

1 0

Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 30 May 2023
by Julie Bisland May 23, 2023

May 23, 2023

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 30 May 2023 at 16:00 UTC for 90 minutes. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. To join - Zoom Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 <https://urldefense.com/v3/__https:/icann.zoom.us/j/95363727469?pwd=N3A3OWFS…> Passcode: @TP/^*4wg# If you are joining via audio only: One tap mobile: US: +19294362866,,95363727469#,,,,*7490739013# or +13017158592,,95363727469#,,,,*7490739013# Telephone: Dial (for higher quality, dial a number based on your current location): US: +1 929 436 2866 or +1 301 715 8592 or +1 312 626 6799 or +1 669 900 6833 or +1 253 215 8782 or +1 346 248 7799 or 888 788 0099 (Toll Free) or 877 853 5247 (Toll Free) Webinar ID: 953 6372 7469 Passcode: 7490739013 International numbers available: https://icann.zoom.us/u/acdLFXPLp6 <https://urldefense.com/v3/__https:/icann.zoom.us/u/acdLFXPLp6__;!!PtGJab4!v…> Members, alternates, and observers all have different access and participation directions, please read below! ALL: Before joining the call: * Please send apologies and dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior<https://www.icann.org/resources/pages/expected-standards-2016-06-28-en> * Visit the Wiki Agenda meeting page: https://community.icann.org/x/-YLKDQ * Time conversion link: https://tinyurl.com/8rrs9a78 ONLY FOR MEMBERS & ALTERNATES: * Staff will promote members and alternates to panelist once joined. * Chat: Please select Everyone so everyone can see your chat, and so it’s captured in the recording. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. * Alternate assignments will be publicly posted to the Alternate Log-Transfer Policy Review PDP<https://community.icann.org/x/V4aUCQ> wiki page. * Alternates (not replacing a member): Rename your line by adding 3 Zs (zzz) before your name and add, your affiliation - alternate after your name. * Alternates (not replacing a member) are not allowed to engage in the chat or use any of the other zoom room functionalities such as raising hands or agreeing/disagreeing. ONLY FOR OBSERVERS: * Observers will have ability to view member chat and information shared in the zoom webinar room. * Observers will not be able to use chat or raise hands. Thank you. Kind regards, Julie

1 0

Post Call | Transfer Policy Review PDP WG | Tuesday, 23 May 2023
by Julie Bisland May 23, 2023

May 23, 2023

Dear all, All recordings for the Transfer Policy Review PDP WG call held on Tuesday, 23 May 2023 at 16:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/_4LKDQ> (attendance included) and the GNSO Master calendar<https://urldefense.com/v3/__https:/gnso.icann.org/en/group-activities/calen…>. These include: * Attendance * Audio recording * Zoom recording (including audio, visual, rough transcript, and chat.) * Transcript * Agenda and Notes/Action Items As a reminder only members and alternates can join the call as a Panelist, observers can join as an Attendee to listen. For additional information, you may consult the mailing list archives <https://mm.icann.org/pipermail/gnso-tpr/> and the main wiki page<https://community.icann.org/x/P4aUCQ>. Thank you. With kind regards, Julie

1 0

**AT THE TOP OF THE HOUR** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 23 May 2023
by Julie Bisland May 23, 2023

May 23, 2023

**AT THE TOP OF THE HOUR** Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 23 May 2023 at 16:00 UTC for 90 minutes. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. To join - Zoom Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 <https://urldefense.com/v3/__https:/icann.zoom.us/j/95363727469?pwd=N3A3OWFS…> Passcode: @TP/^*4wg# If you are joining via audio only: One tap mobile: US: +19294362866,,95363727469#,,,,*7490739013# or +13017158592,,95363727469#,,,,*7490739013# Telephone: Dial (for higher quality, dial a number based on your current location): US: +1 929 436 2866 or +1 301 715 8592 or +1 312 626 6799 or +1 669 900 6833 or +1 253 215 8782 or +1 346 248 7799 or 888 788 0099 (Toll Free) or 877 853 5247 (Toll Free) Webinar ID: 953 6372 7469 Passcode: 7490739013 International numbers available: https://icann.zoom.us/u/acdLFXPLp6 <https://urldefense.com/v3/__https:/icann.zoom.us/u/acdLFXPLp6__;!!PtGJab4!v…> Members, alternates, and observers all have different access and participation directions, please read below! ALL: Before joining the call: * Please send apologies and dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior<https://www.icann.org/resources/pages/expected-standards-2016-06-28-en> * Visit the Wiki Agenda meeting page: https://community.icann.org/x/_4LKDQ * Time conversion link: https://tinyurl.com/3769xau8 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/3769xau8__;!!PtGJab4!7Mrr4xj…> ONLY FOR MEMBERS & ALTERNATES: * Staff will promote members and alternates to panelist once joined. * Chat: Please select Everyone so everyone can see your chat, and so it’s captured in the recording. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. * Alternate assignments will be publicly posted to the Alternate Log-Transfer Policy Review PDP<https://community.icann.org/x/V4aUCQ> wiki page. * Alternates (not replacing a member): Rename your line by adding 3 Zs (zzz) before your name and add, your affiliation - alternate after your name. * Alternates (not replacing a member) are not allowed to engage in the chat or use any of the other zoom room functionalities such as raising hands or agreeing/disagreeing. ONLY FOR OBSERVERS: * Observers will have ability to view member chat and information shared in the zoom webinar room. * Observers will not be able to use chat or raise hands. Thank you. Kind regards, Julie

1 0

**REMINDER** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 23 May 2023
by Julie Bisland May 22, 2023

May 22, 2023

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 23 May 2023 at 16:00 UTC for 90 minutes. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. To join - Zoom Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 <https://urldefense.com/v3/__https:/icann.zoom.us/j/95363727469?pwd=N3A3OWFS…> Passcode: @TP/^*4wg# If you are joining via audio only: One tap mobile: US: +19294362866,,95363727469#,,,,*7490739013# or +13017158592,,95363727469#,,,,*7490739013# Telephone: Dial (for higher quality, dial a number based on your current location): US: +1 929 436 2866 or +1 301 715 8592 or +1 312 626 6799 or +1 669 900 6833 or +1 253 215 8782 or +1 346 248 7799 or 888 788 0099 (Toll Free) or 877 853 5247 (Toll Free) Webinar ID: 953 6372 7469 Passcode: 7490739013 International numbers available: https://icann.zoom.us/u/acdLFXPLp6 <https://urldefense.com/v3/__https:/icann.zoom.us/u/acdLFXPLp6__;!!PtGJab4!v…> Members, alternates, and observers all have different access and participation directions, please read below! ALL: Before joining the call: * Please send apologies and dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior<https://www.icann.org/resources/pages/expected-standards-2016-06-28-en> * Visit the Wiki Agenda meeting page: https://community.icann.org/x/_4LKDQ * Time conversion link: https://tinyurl.com/3769xau8 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/3769xau8__;!!PtGJab4!7Mrr4xj…> ONLY FOR MEMBERS & ALTERNATES: * Staff will promote members and alternates to panelist once joined. * Chat: Please select Everyone so everyone can see your chat, and so it’s captured in the recording. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. * Alternate assignments will be publicly posted to the Alternate Log-Transfer Policy Review PDP<https://community.icann.org/x/V4aUCQ> wiki page. * Alternates (not replacing a member): Rename your line by adding 3 Zs (zzz) before your name and add, your affiliation - alternate after your name. * Alternates (not replacing a member) are not allowed to engage in the chat or use any of the other zoom room functionalities such as raising hands or agreeing/disagreeing. ONLY FOR OBSERVERS: * Observers will have ability to view member chat and information shared in the zoom webinar room. * Observers will not be able to use chat or raise hands. Thank you. Kind regards, Julie

1 0

Proposed agenda for meeting #92 on Tuesday 23 May 2023 at 16:00 UTC
by Emily Barabas May 19, 2023

May 19, 2023

Dear Working Group members, Please find below the proposed agenda for the next meeting scheduled to take place on Tuesday 23 May at 16:00 UTC. Before the call, please review the following: * Metrics in the Transfer Policy Status Report<https://www.icann.org/uploads/ckeditor/IRTPPSRRevised_GNSO_Final.pdf> relevant to charter question g1: * Amount of Transfer Dispute Cases, Won/Lost/No Decision, 2010 - 2017, page 30 * Transfer Complaints Handled by Contractual Compliance, organized by closure code, pages 37-45 * Transfer-Related Inquiries Received by ICANN’s Global Support Center, 1 January 2015 - 23 May 2018, page 47 * Global Support Center Transfer-Related Inquiries Received, 2015 - 2018, page 48 * Examples of Transfer Dispute Cases, pages 83 and 84 * Items relevant to charter question g2: * Requirements in Section 3.1 and 3.2.1 in the Transfer Dispute Resolution Policy<https://www.icann.org/resources/pages/tdrp-2016-06-01-en>. * Decisions of cases published on TDRP providers’ websites: https://www.adndrc.org/decisions/tdrp and https://www.adrforum.com/domain-dispute/search-decisions * ICANN webpages providing information about dispute resolution related to transfers, including availability and applicability of the TDRP. * https://www.icann.org/resources/pages/name-holder-faqs-2017-10-10-en * https://www.icann.org/resources/pages/text-2012-02-25-en * https://www.icann.org/resources/pages/registrar-faqs-2004-11-03-en * https://www.icann.org/resources/pages/tdrp-2016-06-01-en * https://www.icann.org/resources/pages/providers-fc-2012-02-25-en * https://www.icann.org/resources/pages/unauthorized-2013-05-03-en * https://www.icann.org/resources/pages/dispute-resolution-2012-02-25-en * https://www.icann.org/resources/pages/dndr-2012-02-25-en * https://www.icann.org/en/blogs/details/do-you-have-a-domain-name-heres-what… * https://www.icann.org/en/blogs/details/do-you-have-a-domain-name-heres-what… Kind regards, Caitlin, Berry, Julie, and Emily ------------------------------------------------------------------------------------------------------------------- Transfer Policy Review - Meeting #92 Proposed Agenda 23 May 2023 1. Welcome and Chair updates 2. Recap Outcomes - Last Week’s Call 3. Charter Question g1 4. Charter Question g2 5. Charter Question g3 (time permitting) 6. AOB Emily Barabas Policy Development Support Senior Manager Internet Corporation for Assigned Names and Numbers (ICANN) Phone: +31 (0)6 84507976 www.icann.org<http://www.icann.org/>

1 0

Poll closes tomorrow: Please share availability for August TPR meetings - Deadline Friday, 19 May
by Emily Barabas May 18, 2023

May 18, 2023

Final reminder to WG members – Please fill out this brief poll by tomorrow, Friday, 19 May: https://forms.gle/c7d1Aduo5YLct4ST7 Kind regards, Caitlin, Julie, Berry, and Emily From: Emily Barabas <emily.barabas(a)icann.org> Date: Friday, 12 May 2023 at 13:14 To: "gnso-tpr(a)icann.org" <gnso-tpr(a)icann.org> Subject: Reminder: Please share availability for August TPR meetings - Deadline Friday, 19 May Dear working group members, As a reminder, please fill out this brief poll by Friday, 19 May: https://forms.gle/c7d1Aduo5YLct4ST7 Kind regards, Caitlin, Julie, Berry, and Emily From: Emily Barabas <emily.barabas(a)icann.org> Date: Wednesday, 10 May 2023 at 09:44 To: "gnso-tpr(a)icann.org" <gnso-tpr(a)icann.org> Subject: Action Item: Please share availability for August TPR meetings - Deadline Friday, 19 May Dear working group members, Please take a moment to share your availability for working group meetings in August by completing this brief poll: https://forms.gle/c7d1Aduo5YLct4ST7 This poll will close on Friday, 19 May. Kind regards, Caitlin, Julie, Berry, and Emily Emily Barabas Policy Development Support Senior Manager Internet Corporation for Assigned Names and Numbers (ICANN) Phone: +31 (0)6 84507976 www.icann.org<http://www.icann.org/>

1 0

Post Call | Transfer Policy Review PDP WG | Tuesday, 16 May 2023
by Julie Bisland May 16, 2023

May 16, 2023

Dear all, All recordings for the Transfer Policy Review PDP WG call held on Tuesday, 16 May 2023 at 16:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/_YLKDQ> (attendance included) and the GNSO Master calendar<https://urldefense.com/v3/__https:/gnso.icann.org/en/group-activities/calen…>. These include: * Attendance * Audio recording * Zoom recording (including audio, visual, rough transcript, and chat.) * Transcript * Agenda and Notes/Action Items As a reminder only members and alternates can join the call as a Panelist, observers can join as an Attendee to listen. For additional information, you may consult the mailing list archives <https://mm.icann.org/pipermail/gnso-tpr/> and the main wiki page<https://community.icann.org/x/P4aUCQ>. Thank you. With kind regards, Julie

1 0

Notes and action items: TPR WG Meeting #91 - 16 May at 1600 UTC
by Julie Hedlund May 16, 2023

May 16, 2023

Dear TPR WG members, Please find below the brief notes and action items from today’s meeting. The next meeting will be on Tuesday, 23 May at 1600 UTC. Best regards, Emily, Julie, Berry, and Caitlin ACTION ITEMS/HOMEWORK: Re: Charter Question G1 and G2 on TDRP for consideration and discussion at the next meeting: WG members to review Sections 3.1 and 3.2.1 of the Transfer Dispute Resolution policy in preparation for discussion of Charter Question G2 – see: https://www.icann.org/resources/pages/tdrp-2016-06-01-en. Notes: Transfer Policy Review - Meeting #91 Proposed Agenda 16 May 2023 1. Roll Call & SOI updates 2. Welcome and Chair Updates * Remind everyone to please fill out the poll before the end of this week with their availability for meetings in August. See: https://forms.gle/c7d1Aduo5YLct4ST7. * Project Work Plan: We are working towards having substantial output by ICANN77. Have meetings scheduled for June and July. No open action items. 3. Review Draft Preliminary Recommendations on TEAC – see attached slides. f2) The time frame (4 hours) for registrars to respond to communications via the TEAC channel has been raised as a concern by the Transfer Policy Review Scoping Team and in survey responses. Some have expressed that registries must, in practice, have 24x7 coverage by staff members with the appropriate competency to meet this requirement and the language skills to respond to communications from around the world. Is there merit to concerns that the requirement disproportionately impacts certain registrars, namely: 1. Registrars located in regions outside of the Americas and Europe, because of significant time zone differences? 2. Small and medium-sized registrars, which may not have a sufficiently large team to have 24x7 staff coverage with the necessary competency? 3. Registrars in countries where English is not the primary language, who may, in practice, need to have English-speaking TEAC contacts to respond to requests in English? f3) To what extent should the 4-hour time frame be revisited in light of these concerns? Are there alternative means to address the underlying concerns other than adjusting the time frame? Draft Preliminary Recommendation #G2-1: Section I.A.4.6.3 of the Transfer Policy states, “Messages sent via the TEAC communication channel must generate a non-automated response by a human representative of the Gaining Registrar. The person or team responding must be capable and authorized to investigate and address urgent transfer issues. Responses are required within 4 hours of the initial request, although final resolution of the incident may take longer.” The working group recommends that the policy must be revised to update the required timeframe for initial response from 4 hours to 24 hours. Rationale in Brief: Reduce risk of gaming, reduce burden on registrars (especially smaller companies and those in time zones outside of Europe and the Americas), while still providing a reasonable response timeframe. Currently RAA has a 24 hour SLA for Rrs to provide a non-automated initial response to reports of illegal activity. This may be considered an analogous situation. Discussion: * Early indication that this seems acceptable. Good to get confirmation. * No opposition and several support in the chat; we can go with this. f4) Section I.A.4.6.2 of the Transfer Policy states that “Communications to a TEAC must be initiated in a timely manner, within a reasonable period of time following the alleged unauthorized loss of a domain.” The Transfer Policy Review Scoping Team noted that this timeframe should be more clearly defined. Is additional guidance needed to define a “reasonable period of time” after which registrars should be expected to use a standard dispute resolution process? Note: The working group has considered two items related to this charter question: 1. The timeframe for initial contact to the TEAC following the alleged unauthorized loss of a domain. 2. The timeframe for final resolution of an issue raised through the TEAC channel. Draft Preliminary Recommendation #G2-2: Section I.A.4.6.2 of the Transfer Policy states in part, “. . . Communications to a TEAC must be initiated in a timely manner, within a reasonable period of time following the alleged unauthorized loss of a domain.” The working group recommends that the Transfer Policy must be updated to state that the initial communication to a TEAC is expected to occur no more than [30 days] following the alleged unauthorized loss of a domain. If the initial communication to the TEAC occurs more that [30 days] following the alleged unauthorized loss of a domain, the registrar contacting the TEAC must provide a detailed written explanation to the TEAC justifying why this is an emergency situation that must be addressed through the TEAC and providing information about why earlier contact to the TEAC was not possible. Rationale in Brief: Defines “a reasonable period of time” while allowing flexibility for exceptional circumstances that may still constitute an emergency. The 30-day period corresponds to the 30-day post transfer lock period. Draft Preliminary Recommendation #G2-3: Once a registrar has provided an initial non-automated response to a TEAC communication as described in Section I.A.4.6.3 of the Transfer Policy, that registrar must provide additional, substantive updates by email to the registrar who initiated the TEAC communication. These updates must be sent every [48 hours] [72 hours] until work to resolve the issue is complete and must include specific actions taken to work towards resolution. Rationale in Brief: Introduces additional transparency and accountability without providing strict deadlines that may not be appropriate or feasible to meet, even when both registrars are working diligently towards resolution of the issue. Discussion: Recommendation #G2-2: * 30 days aligns with the 30-day lock. * Make as many dates as consistent as possible – tether it to other lock periods – say the same as the post transfer lock, rather than 30 days. * Appreciate alignment with locks, but there are times when they are discovered after 30 days that are still legitimate: maybe say “discovery” of the unauthorized loss of a domain. * Current suggested recommendation allows it to go longer than 30 days. * Would not recommend “discovery” as a term. * Today it doesn’t specify any time period. Recommendation #G2-3: * 72 hours covers weekends. * Days is fine as well. * We used both hours and days in the Phase 1A recommendations, we will update to be consistent. * We will go with 72 hours/3-day window. f5) According to section I.A.4.6.2 of the Transfer Policy, the TEAC may be designated as a telephone number, and therefore some TEAC communications may take place by phone. The Transfer Policy Review Scoping Team flagged this provision as a potential item for further consideration. Do telephone communications provide a sufficient “paper trail” for registrars who may later wish to request a transfer “undo” based on failure by a TEAC to respond? Such a request would require the registrar to provide evidence that a phone call was made and not answered, or a call back was not received within 4 hours. Noting this requirement, should the option to communicate by phone be eliminated? Is an authoritative “system of record” for TEAC communications warranted? If so, what are the requirements for such a system? Draft Preliminary Recommendation #G1-4: Section I.A.4.6.2 states in part that “The TEAC point of contact may be designated as a telephone number or some other real-time communication channel and will be recorded in, and protected by, the ICANN registrar portal.” The working group recommends that the registrar must provide an email address for the TEAC point of contact and may additionally provide a telephone number or other real-time communication channel. Draft Preliminary Recommendation #G1-5: The working group recommends that initial communication to the TEAC described in Section I.A.4.6.2 of the Transfer Policy must either be in the form of email or be accompanied by an email communication to the TEAC. This email “starts the clock” for the 24-hours response timeframe specified in Preliminary Recommendation #G2-1. The registrar receiving the TEAC communication must respond by email within 24 hours. The registry and ICANN org must be copied on both the initial email to the TEAC and the initial response by the TEAC. Rationale in Brief: Ensures that there is a paper trail associated with each initial TEAC contact without creating complex new requirements for an system of record that may be seldom used. Discussion: * Question: Feel like we talked about how the registry would know who to copy – is there an email address? Answer: Good question – thoughts? * Maybe the just contact the registry transfer contact? * Not an issue in the preliminary, but we should define how to get that information. * Should we specify “registry transfer contact”? * Not aware this question was in doubt – but not sure that there is a registry contact; check to see if there is a contact in NSp – just do what the registrar is doing now; the registries already offer support; not sure there needs to be another contact. * Should there be a specific email for this to go to? Does that make sense for the registry? * Should make sure there is a clear place for this information to be accessed. What is that process? * Agreement with the suggested recommendation. * Rec could be that there is revisit of the current contacts in NSp/wherever that is specific to the TEAC situations. 4. Consider outstanding questions on TEAC f1) Is additional data needed to support evaluation of the effectiveness of the TEAC mechanism? If so, what data is needed? Some support has been expressed for the idea that more data is needed to evaluate the effectiveness of the TEAC mechanism. Some working group members indicated that registrars should be required to track and report on specific data points related to the TEAC going forward. Types of information the BC, RySG, and NCSG identified as potentially useful: * Number of times TEAC channel is used * Modes of contact to TEAC, and whether these are satisfactory * Steps taken before contacting TEAC * Quality of initial response by TEAC * Whether the timeframe for response is satisfactory * Circumstances prompting use of TEAC * Number of cases where there are problems associated with use of the TEAC, including abuse of the channel * Circumstances of issues experienced with the TEAC * Type of resolution of case raised through TEAC * Level of satisfaction with final resolution In addition the WG charter identifies the following metrics that could be used to measure whether policy goals are achieved: * Number of TEAC requests responded to within the required timeframe vs. number of TEAC requests NOT responded to within the required timeframe * Number of TEAC requests resulting in a “transfer undo” To Discuss: * The working group appears to be converging on recommendation that initial contact and response via the TEAC includes an email “paper trail.” * At this time, the working group is not recommending a centralized system of record. Such a system would potentially be able to provide aggregated data about number of contacts, timeframe for response, etc. * An email paper trail is a source of information, but turning that information into data requires manual work. * Some data points might be fairly easy to collect and aggregate, for example number of times TEAC channel is used, amount of time it takes for a registrar to respond when the TEAC channel is used, and number of times registries undo a transfer as a result of a registrar missing the TEAC SLA. * Other data points require recording narrative responses and analyzing the fact patterns of cases. * What are the cost/benefit tradeoffs of recommending that these metrics are collected and analyzed? * Who will be responsible for the data collection/analysis? * Are there alternatives that the group wants to consider beyond requirements for data collection/reporting? Discussion: * Important question: Who is responsible for tracking and coordinating that information? * Do we miss something on the closure side – we don’t say what happens when it’s resolved – is that necessary? We don’t know the outcome unless someone supplies that information. * If ICANN is being copied then it is a central repository, but then there would be resources require to gather and track the data. * Like the idea of ICANN being the collector and reporter. Some identifying information probably shouldn’t be collected. * Does anyone need to track this in real time, or just when there is a question that requires a review – to analyze it at a certain point in time; could be accommodated more easily. * Emily, staff: If the WG is going to trend to a recommendation that ICANN needs to monitor all activity and track – should be clear what is expected to be tracked (different from what Compliance tracks, which would be complaints), what purpose tracking would serve, how would it inform future policy development? One of the advantages of a centralized system is dates and numbers. * Just the emails that we recommend ICANN get copied on for TEAC would provide a simple data output. * Seems simple, but it still would require resources. * Berry, staff: Hesitant about where this is going. Very few TDRPs, but don’t know the volume of transfer disputes, some percentage of which involve TEAC. Trying to track TEAC traffic would not be easy – it would be unstructured data, so there is a quality issue. Processing any decentralized and unstructured data is burdensome. * Don’t know how often the TEAC gets used today. How do you know about follow-up emails and match them up? What will you use them for? Is there a trigger, or just a backward look? * The limited data obtainable from the TEAC procedure would not be helpful – would be nice to have the data the next time we make policy. * Berry, staff: If the WG were going to produce a recommendation on metrics, then yes, I think Org would want to consider leveraging NSp to do such a thing. * Don’t think the WG is recommending a centralized repository of data. Doesn’t seem to be enough support to recommend anything specific. * Emily, staff: If the WG has no recommendation relating to metrics, coming back to the recommendation of copying ICANN org on TEAC emails: what is the purpose for ICANN org to collect these data so we can consider any GDRP considerations. * It was that third-party look, to avoid the “he said, she said” scenario. * Berry, staff: If there is no enforcement purpose, just to increase the legitimacy of the issue, it could set the expectation that ICANN org could get involved in a dispute when it couldn’t. So can’t the Registrar just file a complaint with Compliance for no response? What does the CC of Org on the email solve? * Having the copy could allow ICANN to provide a paper trail. * What is ICANN org supposed to do with this data? If we want something useful it should be a centralized database, no email copies. * Holida, staff: From a practical perspective when ICANN has been copied in the past it has created confusion --- made the registrar think incorrectly that they didn’t have to respond because ICANN was involved. We already have a system for tracking complaints. * Think the registry should be cc’d, not ICANN. * Disagree: Some ticketing systems ignore a cc. Also, registry might be copied on something in which they might not need to be involved. * Berry, staff: The difference though is a purpose of processing data for an actual complaint vs. bulk processing waiting for one to become a complaint. * The debate is whether it is needed or not – maybe not a MUST to send to the registry, but a COULD or SHOULD. * Sounds like everyone is moving away from copying ICANN but maybe the registry. * Hard to prove the negative that the registrar didn’t respond. Could look at a copy of the original request to the gaining registrar, but we don’t know if it was responded to. So the registry does their own outreach to the gaining registrar – like a do-over. * Emily, staff: Curious from the registries perspective: Is there a RySG position on being copied on the TEAC emails? * Rick Wilhelm, RySG: If the registry is copied on the original request to the gaining registrar that’s okay, but we still don’t know if the gaining registrar responded, so we still have to do our own confirmation. * We don’t having anything in the recommendations to provide a timeline for the registry. Do we need that? * Would consider a recommendation do the extra step of validating. * Rick Wilhelm, RySG: The registries have a requirement to undo a transfer within 5 days if no response – so there already is a timeline and registries also already do due diligence before reverting. * Should there be a recommendation of what the registry should do? Do we need that? * Rick Wilhelm, RySG: Registries would prefer that there not be anything more prescriptive than what already exists. * WG is in agreement to remove this sentence from F5: “The registry and ICANN org must be copied on both the initial email to the TEAC and the initial response by the TEAC.” Also, that no change is needed on F6/F7. (See below.) 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? Issue i Status: RySG suggests “that ICANN Org include the Rr TEAC in the list of Rr contacts that it regularly supplies to the ROs.” Policy staff is investigating the history of this issue and any other relevant information to be shared for the working group’s consideration. 5. Charter Question G1 and G2 on TDRP – moved to next meeting: Section 3.1 and 3.2.1 of the Transfer Dispute Resolution policy in preparation for discussion of Charter Question G2:https://www.icann.org/resources/pages/tdrp-2016-06-01-en. 6. AOB

1 0